Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4F4E5628.7030707@apache.org>
Date: Wed, 29 Feb 2012 16:45:28 +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:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: <dev@jackrabbit.apache.org>
Subject: Re: [jr3 trade consistency for availability]
References: <4F4527A9.6060507@adobe.com>
 <9C0FC4C8E9C29945B01766FC7F9D389816E3A56CC4@eurmbx01.eur.adobe.com>
 <4F462659.4080102@apache.org> <4F4CE0D9.6020900@gmail.com>
 <9C0FC4C8E9C29945B01766FC7F9D389816E3CC8F39@eurmbx01.eur.adobe.com>
 <2C4F1A4A-13EF-4B2A-8872-5C48872AF5BA@adobe.com>
 <9C0FC4C8E9C29945B01766FC7F9D389816E3CC90D6@eurmbx01.eur.adobe.com>
 <1DB6248A-8355-4E42-85D8-8EBF7AB55EC5@adobe.com>
In-Reply-To: <1DB6248A-8355-4E42-85D8-8EBF7AB55EC5@adobe.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit


On 29.2.12 16:30, Dominique Pfister wrote:
> Hi,
>
> On Feb 29, 2012, at 2:52 PM, Marcel Reutegger wrote:
>
>> Hi,
>>
>>> On Feb 28, 2012, at 3:54 PM, Marcel Reutegger wrote:
>>>
>>>> I'd solve this differently. Saves are always performed on one
>>>> partition,
>>>> even if some of the change set actually goes beyond a given partition.
>>>> this is however assuming that our implementation supports dynamic
>>>> partitioning and redistribution (e.g. when a new cluster node is added
>>>> to the federation). in this case the excessive part of the change set
>>>> would eventually be migrated to the correct cluster node.
>>>
>>> I'd like to better understand your approach: if we have, say,
>>> Partitions P and Q, containing subtrees /p and /q, respectively, then
>>> a save that spans elements in both /p and /q might be saved in P
>>> first, and later migrated to Q? What happens if this later migration
>>> leads to a conflict?
>>
>> I guess this would be the result of a concurrent save when there's
>> an additional conflicting save under /q at the same time. good
>> question... CouchDB solves this with a deterministic algorithm
>> that simply picks one revision as the latest one and flags the conflict.
>> maybe we could use something similar?
>
> So, this could result in a save on P that initially succeeds but
> ultimately fails, because the concurrent one on Q wins? I'm wondering
> how this could be reflected to an MK client: if a save corresponds to a
> MK commit call that immediately returns a new revision ID, would you
> suggest that the mentioned algorithm adds a "shadow" commit (leading to
> a new head revision ID) on P, that effectively reverts the conflicting
> save on P?

That's an idea I mentioned earlier already [1]: make cluster sync 
transparent to JCR sessions. That is, any modification required by the 
sync, should look like just another session operation to JCR clients 
(i.e. there should also be observation events for such changes).

Michael

[1] 
https://docs.google.com/presentation/pub?id=131sVx5s58jAKE2FSVBfUZVQSl1W820_syyzLYRHGH6E&start=false&loop=false&delayms=3000#slide=id.g4272a65_0_39

>
> Dominique
>
>>
>> regards
>> marcel
>>
>>
>