[
https://issues.apache.org/jira/browse/ZOOKEEPER-1262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13139368#comment-13139368
]
Patrick Hunt commented on ZOOKEEPER-1262:
-----------------------------------------
my response on list:
You're right, we should have an "error handling" section in that doc,
the assumption is that this is the algo when things are working, but
what happens if things go awry?
One way to handle the issue you describe, is when the client
reconnects to the cluster, if the session is not expired it could look
at any outstanding requests it made and not gotten responses for. In
this case it could scan the list looking for any znode that it created
(see the Stat object) and make a determination based on that.
I see you entered ZOOKEEPER-1262, perhaps you could supply a patch to
the docs detailing this?
> Documentation for Lock recipe has major flaw
> --------------------------------------------
>
> Key: ZOOKEEPER-1262
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1262
> Project: ZooKeeper
> Issue Type: Bug
> Components: documentation
> Affects Versions: 3.3.3
> Reporter: Jordan Zimmerman
>
> The recipe for Locks documented here:
> http://zookeeper.apache.org/doc/trunk/recipes.html#sc_recipes_Locks doesn't
> deal with the problem of create() succeeding but the server crashing before
> the result is returned. As written, if the server crashes before the result
> is returned the client can never know what sequential node was created for
> it. The way to deal with this is to embed the session ID in the node name.
> The Lock implementation in the ZK distro does this. But, the documentation
> will lead implementors to write bad code.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
