[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: unified transaction model proposal

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?
 
> 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>

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.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

--
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/>