If I understand your case correctly, then you'll set a watch on znode y with an exists call. If the exists returns that the node is there, then you'll receive a notification for the deletion of y later on. If the result of the exists call is that the znode doesn't exist, then you know that znode is gone. Does it make sense?
-Flavio On Jul 2, 2013, at 7:48 PM, chao chu <[email protected]> wrote: > Hi Flavio, > > Thanks for your reply. I think that's the exact thing I want to confirm: > when we got the 'NodeDeleted' event due to session expiration, we shouldn't > see the node anymore by calling 'getChildren' of the parent node. > > another related issue just came to my mind about the recipe to implement > leader election, suppose the following sequences: > 1. one participant (A) is watching the node (x) just before it > 2. the node x that A was watching got deleted (due to session expiration or > whatever) > 3. once received the 'NodeDeleted' event, A should check what's the current > node (the node now just before it) it should watch. However, these are two > separate operations: 1) get all the child nodes, get the node (y) with the > sequence just before A 2) A sets a watch on node y. between *getting the > nodes* and *setting the watch on y*, the node y might also be got deleted. > > this should be a rare case and we can retry several times to lower the > chance for this to happen further. But is there a better way to handle this? > > > On Wed, Jul 3, 2013 at 12:54 AM, Flavio Junqueira > <[email protected]>wrote: > >> Hi ChuChao, >> >> I'm not entirely sure I understand the question, so please send some more >> info if this is not the answer you're looking for. In general you don't >> have >> to sync because the events are delivered in order, including the >> notifications for say deleted znodes due to session expiration. An >> exception >> to this rule is the case in which two clients talk directly to each other >> and a client needs to make sure that it doesn't read a stale version >> compared to the other client. But, this is not the case for you, then you >> don't need to sync, just watch for the znode being deleted and react >> accordingly when you receive the notification. >> >> -Flavio >> >> >> >> -----Original Message----- >> From: chao chu [mailto:[email protected]] >> Sent: 02 July 2013 17:44 >> To: [email protected] >> Subject: Do we need a 'sync' to make sure no stale ephemeral nodes observed >> (created by exipred session) >> >> we know that for some performance reasons, different clients may have >> slightly different views of znodes, for example, if client A updated node >> a, >> and it let client B to read the node a, client B might still read the old >> data and it need a 'sync' to see the latest. >> >> Do we need to do the same thing when we concern about reading some stale >> ephemeral nodes which are created by some already expired session? >> >> Thanks & Regards, >> >> -- >> ChuChao >> >> > > > -- > ChuChao
