hadoop-zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Baskinger (JIRA)" <j...@apache.org>
Subject [jira] Commented: (ZOOKEEPER-767) Submitting Demo/Recipe Shared / Exclusive Lock Code
Date Thu, 03 Jun 2010 22:45:56 GMT

    [ 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.


Mime
View raw message