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 Mon, 14 Jun 2010 19:51:13 GMT

    [ https://issues.apache.org/jira/browse/ZOOKEEPER-767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12878717#action_12878717
] 

Sam Baskinger commented on ZOOKEEPER-767:
-----------------------------------------

Thanks of the code-snippet Benjamin. You're absolutely right. Fixed #1.

Regarding #2, when getting a shared lock we ignore existing shared locks and only look for
exclusive locks. Line 225 of the new patch has:

{noformat}
if (child.startsWith(EXLOCK)) { ...
{noformat}

If I'm not confusing the matter, while a single "exclusive lock" node represents a single
exclusive lock, a series of contiguous "shared lock" nodes make up the total of a shared lock.
I took some time to stare at the code in question and corresponding code in the getExclusiveLock()
call and I think they are as we intended them. 

As for #3, wow, I fell asleep at the IDE for that one. Thank you. Any exception will result
in a "roll back" of the lock file creation and the Exception is propagated up the stack.

Now, the larger question of the existing lock implementation, the existing {{WriteLock.java}}
doesn't appear to closely follow the recipe (I'm reading http://hadoop.apache.org/zookeeper/docs/current/recipes.html#sc_recipes_Locks
) . What would prevent us from using it is the lack of first scheduling a lock (creating the
node) and then doing the blocking logic. We realize this is potentially more work, but there
may be some very high reader contention and we need to ensure that a single writer process
doesn't starve. There is the added benefit of being able to observe the finite list of readers
that must complete before the writer can lock.

Other than that, if the existing WriteLock had shared/exclusive coexisting and a block-until-timeout
construct, we would probably prefer to spend our time integrating that code than crafting
up our own. It may well be that the {{SharedExclusiveLock.java}} file has too many production
concerns in it and doesn't suite the goal of a recipe file.

> 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, 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