It depends. Zookeeper is a rather primitive instrument. Libraries like Curator add more complex constructs on top and makes handling them easy. You may create your own Zookeeper abstraction library. Clients should not have to deal with the raw Zookeeper interface, anyway.
The point is: you are making implicit assumptions about how Zookeeper operation semantics should be, and this is currentliy not compatible with the optimistic model of Zookeeper. Your assumptions need to be made explicit and mapped to a transaction model that works for you and only utilize the primitives provided by Zookeeper by not making assumptions beyond what's supported. It's not hard, but requires a bit of an abstraction layer. THAT will actually reduce complexity on the client side. Best regards, --Jürgen On 16.11.2014 03:28, Robin wrote: > Hi Vamsi and Jurgen, > > > > Thanks for your explanation and I believe that your suggestions will work. > However, both of these solutions need extra complexity for client code. If > this can be solved at ZooKeeper side with little effort, it will be great. > > > Thanks, > - Cheng Rao > At 2014-11-15 23:38:12, "Vamsi Devaki" <[email protected]> wrote: >
