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

> 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.


View raw message