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 trade consistency for availability]
Date Tue, 28 Feb 2012 18:49:43 GMT

On 28.2.12 14:54, Marcel Reutegger wrote:
> Hi,
>> On 23.2.12 11:43, Michael Dürig wrote:
>>>>> - Atomicity of save operations?
>>>> how does a temporary violation of atomic saves look like?
>>>> are you thinking of partially visible changes?
>>> I actually had clustering on my mind where the repository is partitioned
>>> across various cluster nodes. If we require atomicity for save operation
>>> across partitions we will need to implement some form of atomic
>>> commitment protocol (i.e. two phase commit). This can cause blocking in
>>> the face of network failures (i.e. less availability).
>> Again, Apache Zookeeper might be worth looking into if we decide to
>> implement ACP.
> 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.

This is a very attractive approach I think. There are still too many 
open questions regarding cluster topology, distribution and scale ATM 
but we should definitely keep this in mind!


View raw message