jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: Making merging changes from concurrent commits more intelligent
Date Thu, 20 Mar 2014 16:06:40 GMT
i agree... in particular since we don't support same name siblings any
more.

On 20/03/14 16:47, "Michael Marth" <mmarth@adobe.com> wrote:

>IMO the benefits (less avoidable conflicts for concurrent writes or
>unexpected creation of SNSs) outweigh the downside (reproduce JR2
>behaviour).
>
>my 2c
>Michael
>
>On 20 Mar 2014, at 16:38, Michael Dürig <mduerig@apache.org> wrote:
>
>> 
>> Hi,
>> 
>> This came up with OAK-1541 where nodes are being added from multiple
>>sessions concurrently:
>> 
>> Session 1: root.addNode("a").addNode("b");
>> Session 2: root.addNode("a").addNode("c");
>> 
>> This currently fails for whichever session saves last because node a is
>>different from the already existing node a. The MicroKernel contract
>>makes this precise: "addExistingNode: a node has been added that is
>>different from a node of them same name that has been added to the
>>trunk."
>> 
>> In OAK-1553 I proposed to relax this contract such that concurrently
>>added nodes could be merged. For the above case the resulting tree would
>>then be
>> 
>> root:{a:{b:{}, c:{}}}
>> 
>> However note that this differs very much from what you usually would
>>get on Jackrabbit 2 when same name siblings enter the stage:
>> 
>> root:{a[1]/b:{}, a[2]/c:{}}
>> 
>> I understand that to be able to add users concurrently (OAK-1541) we
>>need more intelligent merging. However doing so will change the
>>behaviour wrt. Jackrabbit 2 quite significantly.
>> 
>> Thoughts?
>> 
>> Michael
>> 
>> 
>> [1] https://issues.apache.org/jira/browse/OAK-1541
>> [2] https://issues.apache.org/jira/browse/OAK-1553
>


Mime
View raw message