I am comfortable with the locking approach. The watch mechanism is a new feature for me. This gives me a delayed notification that something changed in the lock directory, and so is the earliest time that it makes sense to retry my lock acquistion. However, given the time-delay in getting the notification, the freed lock might have be acquired by someone else before I get there. In which case, I might as well just keep trying to acquire locks at random until my time budget is exhausted and not bother with the watch ?
Are watches triggered as soon as the primary controller applies a change to an object - or are they delivered whenever the client's local zk instance replicates the change at some later time ? Is there a feature to introduce deliberate lag between the primary and its replicas in the ensemble - for development purposes ? That could be useful for exposing latency assumptions. regards, Martin On 24 February 2010 06:05, Ted Dunning <ted.dunn...@gmail.com> wrote: > You have to be careful there of race conditions. ZK's slightly surprising > API makes it pretty easy to get this right, however. > > The correct way to do what you suggest is to read the list of children in > the locks directory and put a watch on the directory at the same time. If > the number of locks equals the number of resources, you wait. If it is > less, you can randomly pick one of the apparently unlocked resources at > random. If you fail, start again by checking the number of resources. > > On Tue, Feb 23, 2010 at 9:09 PM, Martin Waite <waite....@googlemail.com > >wrote: > > > I guess another optimisation might be to count the number of locks held > > first: if the count equals the number of resources, try again later. > But > > I > > suppose that might require a sync call first to ensure that zk instance > my > > client is connected to is up to date. > > > > > > -- > Ted Dunning, CTO > DeepDyve >
