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
