On Fri, Mar 2, 2012 at 3:33 PM, Amirhossein Kiani <[EMAIL PROTECTED]>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
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.