Concurrency Control in Database Systems
•
191
In a centralized DBMS we assumed that
(1) private workspaces were part of the TM,
and (2) data could freely move between a
transaction and its workspace, and between
a workspace and the DM. These assump-
tions are not appropriate in a DDBMS
because TMs and DMs may run at different
sites and the movement of data between a
TM and a DM can be expensive. To reduce
this cost, many DDBMSs employ query
optimization procedures which regulate
(and, it is hoped, reduce) the flow of data
between sites. For example, in SDD-1 the
private workspace for transaction T is dis-
tributed across all sites at which T accesses
data [BF.RN81]. The details of how T reads
and writes data in these workspaces is a
query optimization problem and has no di-
rect effect on concurrency control.
The problem of atomic commitment is
aggravated in a DDBMS by the possibility
of one site failing while the rest of the
system continues to operate. Suppose T is
updating x, y, z stored at DMx, DMy, DMz,
and suppose T's TM fails after issuing dm-
write(x), but before issuing the dm-writes
for y and z. At this point the database is
incorrect. In a centralized DBMS this phe-
nomenon is not harmful because no trans-
action can access the database until the
TM recovers from the failure. However, in
a DDBMS, other TMs remain operational
and can access the incorrect database.
To avoid this problem, prewrite com-
mands must be modified slightly. In addi-
tion to specifying data items to be copied
onto secure storage, prewrites also specify
which other DMs are involved in the com-
mitment activity. Then if the TM fails dur-
ing the second phase of two-phase commit,
the DMs whose dm-writes were not issued
can recognize the situation and consult the
other DMs involved in the commitment. If
any DM received a dm-write, the remaining
ones act as if they had also received the
command. The details of this procedure are
complex and appear in HAMM80.
As in a centralized DBMS, a transaction
T accesses the system by issuing BEGIN,
READ, WRITE, and END operations. In
a DDBMS these are processed as follows.
BEGIN: The TM creates a private work-
space for T. We leave the location and
organization of this workspace unspecified.
READ(X): The TM checks T's private
workspace to see if a copy of X is present.
If so, that copy's value is made available to
T. Otherwise the TM selects some stored
copy of X, say xi, and issues din-read(x,) to
the DM at which x, is stored. The DM
responds by retrieving the stored value of
x, from the database, placing it in the pri-
vate workspace. The TM returns this value
to T.
WRITE(X, new-value): The value of X in
T's private workspace is updated to new-
value, assuming the workspace contains a
copy of X. Otherwise, a copy of X with the
new value is created in the workspace.
END: Two-phase commit begins. For
each X updated by T, and for each stored
copy x, of X, the TM issues a prewrite (x,)
to the DM that stores x,. The DM responds
by copying the value of X from T's private
workspace onto secure storage internal to
the DM. After all prewrites are processed,
the TM issues dm-writes for all copies of all
logical data items updated by T. A DM
responds to dm-write(x,) by copying the
value of x, from secure storage into the
stored database. After all dm-writes are
installed, T's execution is finished.
2. DECOMPOSITION OF THE CONCUR-
RENCY CONTROL PROBLEM
In this section we review concurrency con-
trol theory with two objectives: to define
"correct executions" in precise terms, and
to decompose the concurrency control
problem into more tractable subproblems.
2.1 Serializability
Let E denote an execution of transactions
T1 ..... T,. E is a serial execution if no
transactions execute concurrently in E; that
is, each transaction is executed to comple-
tion before the next one begins. Every serial
execution is defined to be correct, because
the properties of transactions (see Section
1.1) imply that a serial execution terminates
properly and preserves database consist-
ency. An execution is serializable if it is
computationally equivalent to a serial exe-
cution, that is, if it produces the same out-
put and has the same effect on the database
as some serial execution. Since serial exe-
cutions are correct and every serializable
execution is equivalent to a serial one, every
serializable execution is also correct. The
Computing Surveys, Vol. 13, No. 2, June 1981