Distributed Transactions - Transaction Processing - page 309

As suggested by the above example, in order to detect distributed deadlocks, the
servers must exchange information about waits between their transactions. Instead
of explicitly constructing a union of the local wait-for graphs, cycles in the union
graph may also be detected by generating sequences of messages telling about single
wait-for relationships T 0 ! T 0 0 forwarded from a server to another. A cycle exists
in the union graph if such a message is received by the originator of the message
sequence (see the Problems section).

13.7 Replicated Databases

A replicated data item is a data item that comes in two or more copies, or replicas ,
stored at different servers of a distributed database system. A replicated database
is a distributed database that stores replicated data items. Such a database is fully
replicated , if each server stores a replica of every data item, and partially replicated
otherwise.
Actually, every distributed database is partially replicated because it necessarily
replicates at least some metadata, namely, schemas of relations or names of stored
procedures that must be accessible from servers other than the ones that store them.
When actual data such as whole relations or fragments of relations are replicated,
the system catalog at each server must also replicate metadata that tells which data
items are replicated and which servers store the replicas.
An important motivation for replication is to increase data availability in events
of failure: when a server crashes or loses connection to the other servers, replicas
of data items stored in the crashed server may still be accessible at other servers.
Replication can also decrease data-access time and hence improve transaction
throughput and response time, because actions of transactions can be directed to
the closest available replicas; in the best case, local replicas may be available.
Downsides of replication are the increased storage space needed and, most
importantly, the additional burden of maintaining the consistency of the replicas
under updates. If data item .x; v 1 / stored at server s 1 and data item .x; v 2 / stored
at server s 2 are replicas of the same data item (i.e., the one with key x), the system
must maintain the integrity constraint v 1 D v 2 .
Maintaining strong mutual consistency of replicas means that all committed data-
item replicas are to be kept consistent. In a transaction-processing environment, the
only way to ensure this is that every transaction that updates a replicated data item
x also updates all the other replicas of x. In this setting, an update action on a
replicated data item automatically makes the transaction a distributed transaction
whose execution is coordinated by an atomic commit protocol. Such replication is
called transactional replication .
Maintaining strong mutual consistency is often called synchronous replication or
eager replication . Such replication also represents read-one-write-all replication ,
or ROWA , for short: a read action RŒx can be satisfied by accessing a single replica
of x only (and any can do), while an update action WŒx, IŒx or DŒx has to be
performed at all servers that can hold a replica of x.