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
> >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

Reply via email to