Re: unified transaction model proposal

[Andy Bierman <abierman@cisco.com>]

At 06:14 AM 4/28/2004, Juergen Schoenwaelder wrote:
>On Tue, Apr 27, 2004 at 11:16:11AM -0700, Andy Bierman wrote:
>>
>> >Just for clarification: I assume correctly that commit/rollback
>> >only applies to changes created via <edit-config> and not to any
>> >other changes (e.g. <copy-config> or <delete-config) that may be
>> >made since the lock was established.
>> 
>> Good question.  I don't think this is the case though.
>> We have global targets (<candidate> and <running>).
>> If locking is not used, then the agent cannot
>> prevent additional sources from making changes.
>> Also, a <discard-changes> applies to the whole database,
>> not just the changes from the <edit-config> operations
>> from the current session.
>
>So I have to be able to rollback regardless what set of changes have 
>happened. In other words, I have to take a complete snapshot, right?

I'm not sure if that is an implementation detail or a
protocol requirement. 

Our notion of a transaction doesn't align very well with
a traditional database transaction model.  We have optional-to-use
explicit global config locking instead of mandatory-to-use implicit
partial config locking.  The optional-to-use aspect creates
lots of problems like the one you're describing here.

> 
>> We have explicit <lock> and <unlock>.  It's up to the
>> application to use it correctly.  Since this can't
>> be guaranteed, my proposal above won't work.  What
>> if the application didn't use <lock> or did this:
>> 
>>   <lock>
>> 
>>   <edit-config> +   // 1 or more
>>   <commit> OR <discard-changes> 
>> 
>>   <edit-config> +   // 1 or more
>>   <commit> OR <discard-changes> 
>> 
>>   <unlock>
>> 
>> The <lock> can't be used as the start point.
>
>You could argue that the proper thing to do would have been something
>like the following. 
>
>   <lock>
>   <edit-config> +   // 1 or more
>   <commit> OR <discard-changes>
>   <unlock>
>
>   <lock>
>   <edit-config> +   // 1 or more
>   <commit> OR <discard-changes>
>   <unlock>

How about forcing the duration of a lock to be a single transaction:

3 scenarios for <candidate> as target:
---------------------------------------

1) regular commit

   <start-edit>
      <with-lock>true</with-lock>
      <target><candidate/></target>
   </start-edit>
   <edit-config> +
   <commit>    // lock released (if held) after commit

2) confirmed commit

   <start-edit>
      <with-lock>true</with-lock>
      <target><candidate/></target>
   </start-edit>
   <edit-config> +
   <commit>
      <confirmed-commit/>
   </commit>    // lock NOT released after commit
   ...          // lock released after N minutes
   <commit>     // or lock released after 2nd commit

3) discard changes

   <start-edit>
      <with-lock>true</with-lock>
      <target><candidate/></target>
   </start-edit>
   <edit-config> +
   <discard-changes>    // lock released after discard-changes

2 scenarios for <running> as target:
-------------------------------------

4) regular commit

   <start-edit>
      <with-lock>true</with-lock>
      <target><running/></target>
   </start-edit>
   <edit-config> +
   <finish-edit> 
      <persist-changes>true</persist-changes>  // ignored unless #distinct-startup
   </finish-edit>                             // lock released 

5) discard changes

   <start-edit>
      <with-lock>true</with-lock>
      <target><running/></target>
   </start-edit>
   <edit-config> +
   <finish-edit>                    
      <rollback-changes/>                  //  error if #rollback false
   </finish-edit>                          // lock released


Notes:
  - locking is still optional-to-use, but it is forced
    to be a single transaction, instead of free-form.
  - bad things can still happen if <with-lock>='false',
    but no different than any non-NETCONF scenarios
  - #rollback, #rollback-on-error, and #confirmed-commit
    capabilities are needed
  - <start-edit> replaces <lock> 
  - <finish-edit> replaces <unlock>  (needed for <running> target only)


>My understanding was that locks are considered to be short time locks, 
>basically to synchronize changes over multiple boxes. If you are
>concerned that you will not get the second lock, one could for example
>allow to reacquire a lock already held, which would basically change
>the rollback state.

These operations here are all separate RPCs.  The agent cannot know
what order RPCs will be given.  It would be easier to have embedded
locking (see above) than force lock and unlock to be used only one way.


>/js

Andy



--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>