zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <ted.dunn...@gmail.com>
Subject Re: Getting data after the watch
Date Sat, 03 Mar 2012 00:16:34 GMT
On Fri, Mar 2, 2012 at 3:33 PM, Amirhossein Kiani <amirhkiani@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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message