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.
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
> > 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.
> > I
> > suppose that might require a sync call first to ensure that zk instance
> > client is connected to is up to date.
> Ted Dunning, CTO