jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mic...@gmail.com>
Subject Re: Conflict handling in Oak
Date Tue, 18 Dec 2012 13:30:16 GMT


On 18.12.12 12:44, Stefan Guggisberg wrote:
> 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.

See the beginning of the thread an OAK-532.
Michael


>
> 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