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