[
https://issues.apache.org/jira/browse/BOOKKEEPER-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112411#comment-13112411
]
Ivan Kelly commented on BOOKKEEPER-68:
--------------------------------------
The approach I had is at:
https://github.com/ivankelly/bookkeeper/tree/Fencing
Basically, if you fail to update, you jump back to the very start of recovery.
The recovery operation is idempotent in this case, so it will succeed in
opening for reading. For NN, there would be another mechanism to ensure that
only one ledger is open for writing at a time, as really that's where we want
collisions to happen if they do happen.
Flavio made a good point yesterday that multiple concurrent recoveries will
steal bandwidth from each other though, which I think is the best argument for
erroring one of them out.
Actually, the BKJournal for NN is available at:
https://github.com/ivankelly/hadoop-common/tree/BKJournal
if you want to take a look.
> Conditional setData
> -------------------
>
> Key: BOOKKEEPER-68
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-68
> Project: Bookkeeper
> Issue Type: Bug
> Reporter: Flavio Junqueira
> Assignee: Flavio Junqueira
> Attachments: BOOKKEEPER-68.patch
>
>
> The write to ZooKeeper to store ledger metadata when closing a ledger must be
> conditional, otherwise concurrent clients might end up writing in a way that
> the update of a client overwrites the update of the other.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
