Benjamin Reed commented on ZOOKEEPER-767:

-1 there are a couple of problems with the implementation:

1) shouldn't you check to see if you already have a lock before you do the 
create? that will remove the code right after the create in the getXXXXLock() 

2) if you already have an exclusive lock, shouldn't that also count as a shared 

3) the error handling is a bit problematic. a connection loss exception or an 
interrupt can leave a process holding a lock without knowing it.

4) when you go through the children, you may end up checking for the existence 
of every znode before you, which could be wasteful.

i think it may be better to expand the current locking code to handle shared 
lock rather than add a new lock implementation. the current lock recipe 
implementation only does exclusive locks, but it is implemented in a way that 
makes it easy to support shared locks as well and it takes care of the above 

> Submitting Demo/Recipe Shared / Exclusive Lock Code
> ---------------------------------------------------
>                 Key: ZOOKEEPER-767
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-767
>             Project: Zookeeper
>          Issue Type: Improvement
>          Components: recipes
>    Affects Versions: 3.3.0
>            Reporter: Sam Baskinger
>            Assignee: Sam Baskinger
>            Priority: Minor
>             Fix For: 3.4.0
>         Attachments: ZOOKEEPER-767.patch, ZOOKEEPER-767.patch
> Networked Insights would like to share-back some code for shared/exclusive 
> locking that we are using in our labs.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

Reply via email to