Re: [Netconf] Is there a problem with confirmed commits?

[Juergen Schoenwaelder <[e-mail]>]

Hi,

I have not yet understood where you see a problem. In general,
<candidate/> contains arbitrary stuff and hence it is the client's
responsibility to clear any arbitrary stuff found in <candidate/>
after obtaining a lock. If does not really matter whether there has
been a failed confirmed commit before or something else. I think the
general safe pattern is:

lock(candidate)
discard_changes()
push_whatever_needed()
commit()
unlock(candidate)

If you do a confirmed commit and the session disappears, then the lock
will disappear as well. But I do not think this creates a race
condition, or I am just not yet seeing it. Perhaps it helps to write
down the sequence of actions that leads to a race.

/js

On Mon, Jan 14, 2019 at 12:50:38PM +0000, Jonathan Hansford wrote:
> Hi,
> 
> No one seems to be responding to my email and proposed erratum around
> the subject of confirmed commits (apart from Martin), but I would really
> like to know it I am missing something here. As far as I can tell,
> session termination during a confirmed commit leads to unpredictable
> behaviour and I would like to know whether anyone is using confirmed
> commits and how (if at all) they address the issues outlined below. My
> assumptions are that locks are used and :writable-running is not
> supported.
> 
> If the <candidate> and <running> configuration datastores are locked to
> prevent concurrent access, and a confirmed commit sequence is
> interrupted by the session terminating, the locks will automatically be
> released but the server MUST NOT accept a lock on <running> from any
> session if another session has an ongoing confirmed <commit>.
> Consequently, after session termination no client can acquire a <lock>
> on <running>, not even the one that initiated the confirmed <commit>,
> until after the confirmed <commit> has timed out. However, if the
> confirmed <commit> included the <persist> parameter, the original client
> could still issue a <commit> using the persist-id to complete the
> sequence prior to the timeout, even without a lock.
> 
> Of course, the problem now is the race for the new lock on <candidate>.
> If the original client is successful then all is good. But if a new
> client locks <candidate> before the timeout on the confirmed commit,
> whether or not they precede <lock> with <discard-changes>, <candidate>
> will be the same as <running> and the new client will pick up everything
> from the previous session. However, the client won’t be able to lock
> <running> until after the timeout, at which point <running> reverts but
> <candidate> still represents the previous session. If the client tries
> to lock <candidate> after the timeout, <running> will have reverted and
> the lock will only be granted after a <discard-changes> which will cause
> the <candidate> to revert. So, depending on when the lock on <candidate>
> occurs relative to the confirmed commit timeout, the client could be
> editing <candidate> in one of two states. Further, before the timeout on
> the confirmed commit, even if the new client has locked candidate, the
> original client could still issue a confirming commit (they don’t need a
> lock on <candidate> to do so) which would persistently commit any edits
> made by the new client. NOTE: it is not the use of the persist-id that
> introduces this behaviour; a new client would have the same problem even
> if a confirmed commit was not intended to persist beyond a session
> termination.
> 
> If the server also supports the :startup capability then, if the session
> termination was due to the server rebooting, the behaviour above would
> be further complicated by <running> now containing the configuration
> from the <startup> configuration datastore.
> 
> Am I right?
> 
> Jonathan
> 
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus

> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf


-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>