That is one of the strengths of ZK.  Your client would do this:

1) create node, if success client has lock
2) get current node (you get the current version when you do this), if lease
is current and ours, we have the lock, if lease is current and not ours, we
have failed to get the lock
3) try to overwrite node+version from step 2 with our lease claim, if
success, client has the lock
4) if failure in step (3), somebody else jumped ahead of us and updated the
document between steps 2 and 3.  They therefore have the lease or it was the
GC who did it.
5) client has failed to get the lock.  We could repeat step 1 here if we
suspect the GC caused our lossage, but I think that would be of vanishingly
small benefit.

Steps 1, 2 and 3 are not atomic, but they are guaranteed to either get the
lock correctly or fail.  The only surprise waiting for you is in step 3 if
you get a connection loss event between sending the update and getting
confirmation of the update.  That can be recovered after the connection is
automatically restored by going back to step 2.

On Thu, Feb 25, 2010 at 12:07 AM, Martin Waite <waite....@googlemail.com>wrote:

> I cannot see how clients could safely inspect a node and overwrite the
> expiry time if it had expired.  That would involve multiple steps, and so
> not be atomic.
>

Reply via email to