EdColeman commented on issue #637:
URL: https://github.com/apache/accumulo/issues/637#issuecomment-752808599


   Curator is a more general framework and is probably why they allow for the 
additional flexibility, but where we are creating / using locks, I believe that 
we would always want to have the stronger guarantee.  In addition to the 
curator code, the zookeeper recipe documentation also lays out how this can be 
achieved.  
(https://zookeeper.apache.org/doc/r3.5.8/recipes.html#sc_recipes_Locks)
   
   For Accumulo, I believe the pattern we currently expect for lock names is 
lock-[sequential id] - if this were modified to be lock-[uuid]-[sequential id] 
then the basic recipe would work.
   
   This is roughly the same sequence outlined by the zookeeper recipe, modified 
with our current naming convention. This assumes we only create one "lock type" 
in a path - so for example a table lock would be something like 
/accumulo/[instance-id]/table_locks/[table_id]/ any node named lock-* under 
that path is only for locking that table (a unique id / path) - other locks 
would use a different path / root. 
   
   With this convention:
   
   Create a sequential, ephemeral lock node: lock-[uuid] and allow zookeeper to 
assign the sequential id. The generated name would be of the form 
lock-[uuid]-######## with the # assigned by zookeeper.
   Call getChildren (no watch) on the path where the lock node was created to 
get the node names.
   Filter on lock-* 
   Sort using only the sequential id, and find the node with the lowest 
sequential number.
   The node with the lowest sequential id "has the lock"
   - If the uuid of the node with the lowest sequential id is the uuid that the 
process assigned, then that process has the lock.  
   - If the lowest sequential id has a different uuid, then someone else has 
the lock.
   
   I had started implementing this approach before 1.10 was released, but we 
determined that it would be more that a "bug-fix" and would not included in 
that release. So, I put it aside to work other issues. I'll need to check to 
see what additional modifications are required for 2.1.  There were other 
related issues regarding using the session id that I believe that the can also 
be removed with using this approach for locks.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
[email protected]


Reply via email to