Replication of partitions is entirely synchronous and
transactional, with two phase commit. Replicated partitions show
serializable semantics insofar the transactions dealing with
replicated partitions are in serializable isolation.
These processes are transparent to the developer and
administrator. One can program as one would in the case of a
non-clustered database. The below has bearing mostly on
A read with read committed isolation can be done in any copy of
a partition. Read committed reads make no locks nor do they wait
for locks. For uncommitted updated rows, they show the pre-update
state. Thus read committed can be freely load balanced over all
copies of a partition.
A read with repeatable or serializable isolation will always be
done on the first copy of a partition. This is done so as to have
proper serialization of locking. If a row is locked for repeatable
read and another transaction wishes to lock it for update, the
latter will wait. Thus, transactions with locking resolve locking
issues on the first copy of each partition. The first copy is the
copy of the partition held by the first process mentioned in the
partition's group clause of a create cluster. If the process is not
available, the role of the first copy falls on the second, third
and so on. If no host of the hosts mentioned in the group clause is
available, the operation cannot be performed. We will later define
what we mean by available.
Updates to replicated partitions are performed concurrently on
all the copies of the partition. Updates are replicated as they are
made, not at time of commit, hence there is almost no added latency
arising from keeping replicated partitions: When one is ready to
commit, all are.
Distributed deadlock detection is handled by the master host. In
the event of its failure, the function is taken over by the first
node to be available in the sequence of master succession, as