curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Foolish Ewe <foolish...@hotmail.com>
Subject Can Curator's recipes for synchronization be used when the releasing entity is not the locking entity?
Date Wed, 25 Jan 2017 23:03:42 GMT
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

Mime
View raw message