jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: MicroKernelIT#conflictingMove
Date Tue, 15 Jan 2013 11:52:25 GMT


On 15.1.13 11:19, Michael Dürig wrote:
>
>
> On 15.1.13 10:23, Marcel Reutegger wrote:
>>
>>> I looked into why 2 tests failing in MicroKernelIT for MongoMK. One of
>>> them is conflictingMove test. This test passes for MicroKernelImpl
>>> and it
>>> looks like the reason is MicroKernelImpl always commits against head.
>>> Take
>>> a look at CommitBuilder around line 112. There's a check whether
>>> baseRevId
>>> is not equal to currentHead, and if so, the staged tree is reset to
>>> currentHead and the operation is retried. This effectively means that
>>> the
>>> operation is committed against head, right?
>>
>> hmm, not sure. I'd first have to look at the code. if it just blindly
>> commits to
>> head then it's certainly wrong and it also means it wouldn't detect the
>> conflict, right? So, I guess what it does is some kind of rebase.
>
> Yes, the H2 MK does some kind of rebase if the commit is not against the
> current head: it tries to reapply all changes against the current head
> an later tries to merge the resulting changes into trunk. However this
> results in a race condition. See
> https://issues.apache.org/jira/browse/OAK-532
>
>>
>>> We recently changed CommitCommand to commit against baseRevisionId
>>> instead
>>> of head but I'm thinking maybe we should change it back to committing
>>> against head? Or maybe we commit against baseRevisionId but we add some
>>> kind of a conflicting commit detection (although I'm not too sure how
>>> we'd
>>> detect conflicting commits easily). WDYT?
>>
>> this is missing right now. merging with the *head* revision tree is
>> done in
>> CommitCommandNew.mergeNodes(). that is, mergeNodes() basically does
>> the rebase I mentioned above. I recently added a FIXME to this method.
>> I think this is the place where we'd need to find out if there is a
>> conflict.
>>
>
> In a nutshell here is what I think we should do: MK.commit should fail
> on all but conflicts which are trivially merged. This will not be a
> problem for oak-core since oak-core applies changes to private branches
> and will merge these on Session.save. Before merging, branches are
> rebased and that's the place where the more complicated conflict
> handling should go. Due to rebasing the subsequent merge will not
> conflict any more.
>
> See my POC work on https://issues.apache.org/jira/browse/OAK-536 for how
> such a rebase operation could look like. Note that the current
> implementation is not complete yet since it just throws an exception on
> conflicts. I will soon update this to a more complete implementation
> which correctly annotates conflicts such that oak-core can further
> handle these.
>

Just updated the POC implementation to this respect. See 
https://github.com/mduerig/jackrabbit-oak/commits/OAK-536 and 
https://issues.apache.org/jira/browse/OAK-536?focusedCommentId=13553704&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13553704

Michael

> Also note how such an implementation will also solve OAK-464 and OAK-548.
>
> Michael

Mime
View raw message