Hello All:
I would like to use Curator to synchronize mutually exclusive access to a
shared resource, however the entity that wants to release a lock is distinct
from the locking entity (i.e. they are in different JVMS on different
machines). Such cases can occur in practice (e.g. producer/consumer
synchronization, but this isn't quite my use case). Informally I would like
to have operations that behave like the following in a JVM based language:
1. Strict requirements:
* acquire(resourceId, taskId) - Have the task waiting for the resource
suspend until it has mutually exclusive access (i.e. acquires the lock) or
throw an exception if the request is somehow invalid (i.e. bad resource Id, bad
task Id, internal error, etc).
* release(resourceId) - Given a resource, if there is an acquired lock,
release that lock and wake up the next task (in FCFS order) waiting to acquire
the lock if it exists
2. Nice to have (useful for maintenance, etc).
* status(resourceId) - Report if the resource is locked, the current
taskId of the acquirer if the lock is acquired and the (potentially empty)
FCFS list of tasks waiting to acquire the lock.
* releaseAll(resourceId) - remove all pending locks on this resource
However, the semantics of the recipes I've looked at seem to indicate that the
releasing entity must have a handle (either explicit or implicit) of the
lease/lock, e.g.
* http://curator.apache.org/curator-recipes/shared-reentrant-lock.html
states
*
public void release()
Perform one release of the mutex if the calling thread is the same thread that
acquired it. If the
thread had made multiple calls to acquire, the mutex will still be held when
this method returns.
* http://curator.apache.org/curator-recipes/shared-semaphore.html states:
* Lease instances can either be closed directly or you can use these
convenience methods:
public void returnAll(Collection<Lease> leases)
public void returnLease(Lease lease)
So it appears on the surface the the expectation is that the same entity that
acquires a mutex or a semaphore lease is expected to release the mutex or
return the lease.
My questions are:
1. Am I misunderstanding how Curator works?
2. Is there a more appropriate abstraction in Curator for my use case?
3. Can I use one of the existing recipes? Could a releasing entity return a
lease if they had a serialized copy of the lease but weren't the entity
acquiring the lease?
4. If I need to roll my own, should the Curator Framework be able to help
here or should I work at the raw zookeeper level for this use case?
Thanks for your help with this:
Bill
