I read the description several times and, sadly, don’t understand. Maybe someone else? At first blush it almost sounds like a barrier or double barrier: http://curator.apache.org/curator-recipes/barrier.html <http://curator.apache.org/curator-recipes/barrier.html> or http://curator.apache.org/curator-recipes/double-barrier.html <http://curator.apache.org/curator-recipes/double-barrier.html>. But, then, I don’t totally understand. Another thing: Curator InterProcessMutex can be revoked from another process. See http://curator.apache.org/curator-recipes/shared-reentrant-lock.html <http://curator.apache.org/curator-recipes/shared-reentrant-lock.html> “Revoking” - maybe that’s what you want? Other than that, maybe you can restate the problem or give more details.
-Jordan > On Jan 25, 2017, at 6:03 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: > 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 > 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 > <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 > <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: > Am I misunderstanding how Curator works? > Is there a more appropriate abstraction in Curator for my use case? > 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? > 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
