Thanks Mahadev. Randomising the look-up is a good fit for what I am trying
to do, and should minimise the number of look-ups performed.
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.
regards,
Martin
On 23 February 2010 17:50, Mahadev Konar <maha...@yahoo-inc.com> wrote:
> Hi Martin,
> How about this-
>
> you have resources in the a directory (say /locks)
>
> each process which needs to lock, lists all the children of this directory
> and then creates an ephemeral node called /locks/resource1/lock depending
> on
> which resource it wants to lock.
>
> This ephemeral node will be deleted by the process as soon as its done
> using
> the resource. A process should only use to resource_{i} if its been able to
> create /locks/resource_{i}/locks.
>
> Would that work?
>
> Thanks
> mahadev
>
> On 2/23/10 4:05 AM, "Martin Waite" <waite....@googlemail.com> wrote:
>
> > Hi,
> >
> > I have a set of resources each of which has a unique identifier. Each
> > resource element must be locked before it is used, and unlocked
> afterwards.
> >
> > The logic of the application is something like:
> >
> > lock any one element;
> > if (none locked) then
> > exit with error;
> > else
> > get resource-id from lock
> > use resource
> > unlock resource
> > end
> >
> > Zookeeper looks like a good candidate for managing these locks, being
> fast
> > and resilient, and it seems quite simple to recover from client failure.
> >
> > However, I cannot think of a good way to implement this sort of
> one-of-many
> > locking.
> >
> > I could create a directory called "available" and another called
> "locked".
> > Available would have one entry for each resource id ( or one entry
> > containing a list of the resource-ids). For locking, I could loop
> through
> > the available ids, attempting to create a lock for that in the locked
> > directory. However this seems a bit clumsy and slow. Also, the locks
> are
> > held for a relatively short time (1 second on average), and by time I
> have
> > blundered through all the possible locks, ids that were locked at the
> start
> > might be available by time I finished.
> >
> > Can anyone think of a more elegant and efficient way of doing this ?
> >
> > regards,
> > Martin
>
>
