On Fri, Mar 2, 2012 at 3:33 PM, Amirhossein Kiani <amirhki...@gmail.com>wrote:
> Oh.. you are right. The value was skipped because I was getting two of > some values (newer but not older) > So I should restructure my code to not make decisions that rely on locks > created based on node data (unless I come up with a way to sync the state > myself :D) I think I'll implement that by creating a chain of children > instead. > You can atomically update data using ZK pretty easily. That may be all you need. Alternately, the existence of a file serves as a lock. But generally I recommend against using locks as such in distributed systems. There are usually better structures. The statement about getting every value exactly once is not correct though, > because I do get some values twice (when one is skipped) > I think you shouldn't. When a value is skipped, it is because two changes caused one notification. Watches are removed as soon as they are triggered. If the value was n before the change and the change to n+1 triggers your watch, then the get in the watcher will either get n+1 or possibly n+2 if the changes are very fast. In the first case, you will get n+1 and set the watch before the next change. In the second, you will get n+2 and set the watch *after* the change to n+2. The notification after this will give you n+3 or n+4 and you should never see n+2 again.
