Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <50F542F9.8050906@apache.org>
Date: Tue, 15 Jan 2013 11:52:25 +0000
From: =?ISO-8859-1?Q?Michael_D=FCrig?= <mduerig@apache.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: <oak-dev@jackrabbit.apache.org>
Subject: Re: MicroKernelIT#conflictingMove
References: 
 <9C0FC4C8E9C29945B01766FC7F9D3898173DA498CC@eurmbx01.eur.adobe.com>
 <50F53B39.2060505@apache.org>
In-Reply-To: <50F53B39.2060505@apache.org>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit


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