The same doc I sent earlier describes how the sync API can be used to achieve this level of consistency on a particular path.
http://zookeeper.apache.org/doc/r3.4.6/api/org/apache/zookeeper/ZooKeeper.h tml#sync(java.lang.String, org.apache.zookeeper.AsyncCallback.VoidCallback, java.lang.Object) <http://zookeeper.apache.org/doc/r3.4.6/api/org/apache/zookeeper/ZooKeeper. html#sync(java.lang.String,%20org.apache.zookeeper.AsyncCallback.VoidCallba ck,%20java.lang.Object)> However, it's more typical to copy the well-known recipes from the documentation to provide a higher-level construct like distributed lock or barrier. http://zookeeper.apache.org/doc/r3.4.6/recipes.html Sample source code for recipes is available here. https://github.com/apache/zookeeper/tree/release-3.4.6/src/recipes Additionally, you might consider looking at Curator, which provides a higher-level API over the ZooKeeper client. http://curator.apache.org/curator-recipes/ --Chris Nauroth On 11/6/15, 12:50 PM, "[email protected]" <[email protected]> wrote: >Thanks you for your reply. > >In that case is there a standard solution to synchronize different >clients? >If ordered changes to ZK might be seen out of order with certain clients, >then what is the standard way to synchronize clients? > > > >> On Nov 6, 2015, at 3:41 PM, Chris Nauroth <[email protected]> >>wrote: >> >> Hello Kamel, >> >> The behavior you're seeing is not at odds with ZooKeeper's guarantees. >> For more details, please refer to the ZooKeeper programmer's guide >> statements on consistency guarantees. >> >> >>http://zookeeper.apache.org/doc/r3.4.6/zookeeperProgrammers.html#ch_zkGua >>ra >> ntees >> >> >> In particularly, note the sidebar describing how ZooKeeper does not >> guarantee simultaneously consistent cross-client views. >> >> --Chris Nauroth >> >> >> >> >>> On 11/6/15, 12:32 PM, "kamel zaarouri" <[email protected]> >>>wrote: >>> >>> Hi zk-users, >>> >>> Assume this tree: >>> >>> >>> parent1 >>> | |____Child1 >>> | >>> | >>> parent2 >>> |_____<empty> >>> >>> >>> I have 1 watchers on parent1 and another watcher on parent2. I have >>>those >>> watchers setup to receive updates of the child nodes of both parents. >>> >>> Child1 is a non-ephemeral node. >>> >>> If another client: >>> >>> - Creates an ephemeral node (let's call it ephem2) under parent2 >>> then and only then it >>> - Updates Child1 >>> >>> What I am seeing now is that 20% of the time, I receive the callbacks >>>out >>> of order, i.e. I see the Child1 being updated before ephem2 is seen >>> created. >>> >>> Is this is a bug in the client I am using or does ZK not guarantee >>>order >>> in >>> this way? >>> >>> Thank you!, >> >
