[
https://issues.apache.org/jira/browse/ZOOKEEPER-767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12875336#action_12875336
]
Sam Baskinger commented on ZOOKEEPER-767:
-----------------------------------------
Thanks for the feedback Benjamin,
Replying by email removed snippets from your message. Same comments as above,
but with quotes for context (and fewer smilies).
Perhaps I misread the recipe or am missing the philosophy of ZK's atomicity. It
wouldn't be the first time. To your points:
> 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.
We do the create to ensure that we, at some point, will hold a lock. I do want
to do the create, ensuring my turn, and then wait until I'm at the front of the
line (front being defined in the exclusive or shared way).
> 2) if you already have an exclusive lock, shouldn't that also count as a
> shared lock?
There should be a unit test that ensure that this does indeed happen,
semantically. Exclusive locks block all shared access, if I take your meaning
correctly.
> 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.
I thought the API guaranteed that in the event of a connection loss the
EPHEMERAL creation property would guarantee that when the session timed out the
file would be removed and watchers would be signaled.
> 4) when you go through the children, you may end up checking for the
> existence of every znode before you, which could be wasteful.
All but those behind me in the line of locks. This could certainly be optimized
and is something I thought about, but moved past to get the rough
implementation in flight.
> 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.
If the above 4 points hold, then extending the other implementation may be
better for the community. I hope you'll include the code, but if not, we're
very happy with it and appreciate ZooKeeper! Keep up the fine work.
What do you think? What did I miss? :)
Sam Baskinger
> 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.
