[
https://issues.apache.org/jira/browse/ZOOKEEPER-767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12875221#action_12875221
]
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()
methods.
2) if you already have an exclusive lock, shouldn't that also count as a shared
lock?
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
problems.
> 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.
