jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: [jr3 microkernel] Write skew
Date Thu, 01 Dec 2011 16:31:46 GMT

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.


> Bart
>> Michael
>> [1]
>> http://wiki.apache.org/jackrabbit/Clustering%20the%20Microkernel#Replication

View raw message