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!
Michael
