Hi. One of the main functions of Zookeeper and Curator is to handle client failures properly with Ephemeral nodes. In your example its not clear what are requirements for failure handling as now lock owner is not tied to the client.
Best regards, Vitalii Tymchyshyn On Wed, Jan 25, 2017, 6:04 PM Foolish Ewe <[email protected]> wrote: 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: 1. 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). 2. 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). 1. 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. 2. 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
