jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bart van der Schans <b.vandersch...@onehippo.com>
Subject Re: [jr3 microkernel] Write skew
Date Thu, 01 Dec 2011 15:24:49 GMT
On Thu, Dec 1, 2011 at 3:50 PM, Michael Dürig <mduerig@apache.org> wrote:
>
>
> On 1.12.11 14:25, Jukka Zitting wrote:
>>>
>>> Eventually consistent approaches are IMO very hard to get right with JCR
>>> since most operation are assumed to be persisted after dispatch. One
>>> solution I see is to have changes caused by conflict resolution (i.e.
>>> during
>>> convergence) to appear as normal changes as if they where done by other
>>> sessions (see [1]). This would however require changing the revision
>>> model
>>> of the microkernel from linear shaped to tree shaped.
>>
>>
>> This to me sounds like the best approach to take if only there's a way
>> to solve the problems you mention. The main benefit of an eventually
>> consistent model is that a save() call can safely return without the
>> repository having to synchronizes with other cluster nodes or
>> ultimately even other threads within a single node.
>
>
> 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.

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?

Bart


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



-- 
Amsterdam - Oosteinde 11, 1017 WT Amsterdam
Boston - 1 Broadway, Cambridge, MA 02142

US +1 877 414 4776 (toll free)
Europe +31(0)20 522 4466
www.onehippo.com

Mime
View raw message