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
