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: Conflict handling in Oak
Date Tue, 18 Dec 2012 11:49:19 GMT

This is a bit more complicated. In fact it is the other way around: if 
two journal entries commute, the corresponding differences on the nodes 
due not conflict regarding the definition I gave.

OTOH non conflicting changes could still lead to non commuting journal 
entries and thus merging such changes would require journals to be 
adjusted. I'll rephrase below.

On 18.12.12 11:09, Michael Dürig wrote:
>
>
> On 18.12.12 9:38, Thomas Mueller wrote:
>> What I suggest should be merged within the MicroKernel:
>>
>> * Two sessions concurrently add different child nodes to a node
>> ("/test/a"
>> and "/test/b"): this is merged as it's not really a conflict
>>
>> * Two sessions concurrently delete different child nodes ("/test/a" and
>> "/test/b"): this is merged
>>
>> * Two sessions concurrently move different child nodes to another
>> location
>
> I think this can be summed up as:
>
> Only merge non conflicting changes wrt. the children of a node. The
> children of any nodes are its child nodes and its properties. Two
> changes to the children of a node conflict if these children have the
> same name.

If there are no other conflicts (*), merge changes wrt. the children of 
a node. The children of any nodes are its child nodes and its 
properties. Two changes to the children of a node conflict if these 
children have the same name.

(*) see Tom's initial post for what constitutes "other conflicts".

This additional complication somewhat unnecessarily restricts the set of 
mergeable changes. That's why I came up with the proposal to drop 
support for the getJournal() API.

Michael


>
> This has the beauty of simplicity and as Tom notes below also does not
> require the journal to be corrected.
>
>>
>> The reason for this is to allow concurrently manipulating child nodes if
>> there are many child nodes (concurrent repository loading).
>>
>> With this rules, I believe that "2) Furthermore merges should be
>> correctly
>> mirrored in the journal" wouldn't be required, as there are no merges
>> that
>> would cause the journal to change.
>
> Right. The reason for this is - and that's again a very nice property of
> this approach - that for these conflicts the corresponding journal
> entries commute.
>
>
> In addition it would be nice to annotate conflicts in some way. This is
> quite easy to do and would allow upper layers to resolve conflicts based
> on specific business logic. Currently we do something along these lines
> with the AnnotatingConflictHandler [1] in oak-core.
>
> Michael
>
>
> [1]
> https://github.com/jukka/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/commit/AnnotatingConflictHandler.java
>
>
>

Mime
View raw message