Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4ED79426.6070605@apache.org>
Date: Thu, 1 Dec 2011 14:50:14 +0000
From: =?ISO-8859-1?Q?Michael_D=FCrig?= <mduerig@apache.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
 rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: <dev@jackrabbit.apache.org>
Subject: Re: [jr3 microkernel] Write skew
References: <CAFBF1F9.98931%aklimets@adobe.com> <4ED63BEE.6010904@apache.org>
 <CAOFYJNYedNnWA4Z_NWAuGaJBEuav87fY330NXfKAf7_Apx-ruw@mail.gmail.com>
 <4ED751DC.8070606@apache.org>
 <CAOFYJNaN8=EH6bGTWNyB5SctqV+UaQA5LeEAuCH+S=etw1yM8A@mail.gmail.com>
 <4ED76F55.3030001@apache.org>
 <CAOFYJNZvN3xPm9kYg37oTjJ+bQerd9JQn_hzuj1PyqiHQRDxkg@mail.gmail.com>
 <4ED7806E.5010402@apache.org>
 <CAOFYJNYskW7c1wUKbSJWp1+fUPC0phVv1o4shp9tB3U8wKF5mA@mail.gmail.com>
In-Reply-To: 
 <CAOFYJNYskW7c1wUKbSJWp1+fUPC0phVv1o4shp9tB3U8wKF5mA@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit


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.

Michael

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