On 1.12.11 15:24, Bart van der Schans wrote:
I think the toughest question here is how to merge conflicting commits.
There are some quite pathological cases [1]: consider the case where a node
x is moved such that it becomes a child of node y in one session and at them
same time node y is moved such that it becomes a child of node x in another
session. The situation is inherently symmetric and neither move can follow
the other. On merge there seems to be no better way than to undo one (or
both?) of the changes of the sessions.
Isn't the simplest conflicting commit case something like two sessions
setting the same property on the same node to a different value? You
can't merge that and you basically have the same options: one session
(eventually) "wins" (the first or the second write? what is first?),
or both (eventually) loose or you end up with two different versions
of the property/node co-existing, both being valid.
Yes that's probably the simplest conflict case. But there is a subtle
difference: in this case one operation can follow the other. So some
arbitration rule (vector clocks for example) could be used for making
them serializable. In the case of the conflicting move operations such
an arbitration is not possible.
I would expect these kind of scenarios have been worked out in other
"eventual consistent" nosql stores. Could we learn something from them
about conflict resolution? Or can we even use one of those as
persistence store and let the store itself work out the conflict
resolution?
One big difference here is the hierarchical nature of JCR. Other nosql
data bases might not have to cope with hierarchical move conflicts like
the above.
Michael
Bart
Michael
[1]
http://wiki.apache.org/jackrabbit/Clustering%20the%20Microkernel#Replication
