Thanks Jordan, > Assuming the clocks are in sync between all participants…
imho, perfect clock synchronization in a distributed system is very hard (if it can be). > Someone with better understanding of ZK internals can correct me, but this is > my understanding. I think I might have missed some very important and subtile(or obvious?) points of the recipe / ZK protocol. I just can not believe that, there could be such type of a flaw in the lock-recipe, for so long time, without anybody has pointed it out. On Sun, Jan 13, 2013 at 9:31 AM, Jordan Zimmerman <[email protected]> wrote: > On Jan 12, 2013, at 2:30 AM, Hulunbier <[email protected]> wrote: > >> Suppose the network link betweens client1 and server is at very low >> quality (high packet loss rate?) but still fully functional. >> >> Client1 may be happily sending heart-beat-messages to server without >> notice anything; but ZK server could be unable to receive >> heart-beat-messages from client1 for a long period of time , which >> leads ZK server to timeout client1's session, and delete the ephemeral >> node > > I believe the heartbeats go both ways. Thus, if the client doesn't hear from > the server it will post a Disconnected event. > >> But I still feels that, no matter how well a ZK application behaves, >> if we use ephemeral node in the lock-recipe; we can not guarantee "at >> any snapshot in time no two clients think they hold the same lock", >> which is the fundamental requirement/constraint for a lock. > > Assuming the clocks are in sync between all participants… The server and the > client that holds the lock should determine that there is a disconnection at > nearly the same time. I imagine that there is a certain amount of time (a few > milliseconds) overlap here. But, the next client wouldn't get the > notification immediately anyway. Further, when the next client gets the > notification, it still needs to execute a getChildren() command, process the > results, etc. before it can determine that it has the lock. That two clients > would think they have the lock at the same time is a vanishingly small > possibility. Even if it did happen it would only be for a few milliseconds at > most. > > Someone with better understanding of ZK internals can correct me, but this is > my understanding. > > -Jordan
