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

Reply via email to