[
https://issues.apache.org/jira/browse/OAK-560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13556082#comment-13556082
]
Marcel Reutegger edited comment on OAK-560 at 1/17/13 11:31 AM:
----------------------------------------------------------------
Hmm, that looks a bit strange. I'd rather have no flag initially and then mark
it successful.
But does that really solve the issue?
I think it breaks an invariant of the MVCC model.
Consider a commit C performing the following steps:
* C increment nextRevId and read headRevId in sync collection
* C save nodes and commit with new revisionId
* C update headRevId of sync object with new revisionId
* now a client reads from the new head revision, but the MK will *not* return
the nodes from the commit just saved, but nodes in a previous revision
* C marks the commit as valid
* the client performing the exact same read call again (with the same
revisionId) will return the nodes form the new commit!
was (Author: mreutegg):
Hmm, that looks a bit strange. I'd rather have no flag initially and then
mark it successful.
But does that really solve the issue?
I think it breaks an invariant of the MVCC model.
Consider a commit C performing the following steps:
* C increment nextRevId and read headRevId in sync collection
* C save nodes and commit with new revisionId
* C update headRevId of sync object with new revisionId
* now a client reads from the new head revision, but the MK will *not* return
the nodes from the commit just saved, but nodes in a previous revision
* C marks the commit as valid
* performing the exact same call again (with the same revisionId) will return
the nodes form the new commit!
> MongoMK.commit() not atomic
> ---------------------------
>
> Key: OAK-560
> URL: https://issues.apache.org/jira/browse/OAK-560
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: mongomk
> Affects Versions: 0.5
> Reporter: Marcel Reutegger
> Priority: Critical
>
> I created a test (rev 1433995), while reasoning about the optimization we are
> working on in OAK-535. It seem it uncovers a race condition in the commit
> command. I was already wondering in the past if something like this can
> happen, and now it looks like there is indeed a problem.
> Without having further analyzed the sporadic test failure I see, I think it
> is caused by the optimistic commit protocol implemented in CommitCommandNew.
> The internal retry loop saves the nodes, then saves the commit and finally
> save head revision. IIUC this exposes a commit even though it is not yet
> valid and the command may flag it as failed later when it cannot save the
> head revision. And this is indeed the case when I set a breakpoint for the
> failed commit and look inside the commits collection I can see that the
> commit in question is flagged as failed.
> The exception then looks like this:
> org.apache.jackrabbit.mk.api.MicroKernelException: java.lang.Exception:
> Commit with revision 134 could not be found
> at
> org.apache.jackrabbit.mongomk.impl.MongoMicroKernel.merge(MongoMicroKernel.java:214)
> at
> org.apache.jackrabbit.mongomk.impl.MongoMKBranchMergeTest$1.run(MongoMKBranchMergeTest.java:362)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: java.lang.Exception: Commit with revision 134 could not be found
> at
> org.apache.jackrabbit.mongomk.impl.action.FetchCommitAction.execute(FetchCommitAction.java:65)
> at
> org.apache.jackrabbit.mongomk.impl.command.CommitCommandNew.readBranchIdFromBaseCommit(CommitCommandNew.java:145)
> at
> org.apache.jackrabbit.mongomk.impl.command.CommitCommandNew.execute(CommitCommandNew.java:96)
> at
> org.apache.jackrabbit.mongomk.impl.command.CommitCommandNew.execute(CommitCommandNew.java:56)
> at
> org.apache.jackrabbit.mongomk.impl.command.MergeCommand.execute(MergeCommand.java:118)
> at
> org.apache.jackrabbit.mongomk.impl.command.MergeCommand.execute(MergeCommand.java:51)
> at
> org.apache.jackrabbit.mongomk.impl.command.DefaultCommandExecutor.execute(DefaultCommandExecutor.java:38)
> at
> org.apache.jackrabbit.mongomk.impl.MongoNodeStore.merge(MongoNodeStore.java:146)
> at
> org.apache.jackrabbit.mongomk.impl.MongoMicroKernel.merge(MongoMicroKernel.java:212)
> ... 2 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
