jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <mreut...@adobe.com>
Subject RE: [jr3 trade consistency for availability]
Date Tue, 28 Feb 2012 14:54:32 GMT
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.

regards
 marcel

Mime
View raw message