jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: Conflict handling in Oak
Date Tue, 18 Dec 2012 12:44:13 GMT
On Tue, Dec 18, 2012 at 12:49 PM, Michael Dürig <mduerig@apache.org> wrote:
>
> 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.

why should a journal need to be adjusted? MicroKernel#getJournal returns the
exact diffs of successive revisions.

cheers
stefan

> 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