Information Technology Reference
In-Depth Information
r 's tuples need to stay in effect. If, however, the transaction does not commit (e.g.,
because of a system failure), then all of the V attributes have to retain their original
values, so that none of them must be multiplied by two. To accomplish this, the
database management system must be able to undo any updates that have already
been done before the abort of the transaction.
1.5
Transaction States
Formally, we define a
transaction
as a pair .T; ˛/,whereT is the identifier and
˛ is the state of the transaction. The
transaction identifier
is a serial number or
timestamp that uniquely identifies a transaction over a long period of time when
the database system has been in use. More specifically, as will be evident later,
transaction identifiers have to be unique over the set of transactions that either are
currently active (i.e., have not yet committed or rolled back) or have committed or
rolled back but still have traces (i.e., log records) retained in the available log files.
The
transaction state
, ˛, is the sequence of actions performed for the transaction
thus far. Each action in ˛ includes the values for the input arguments with which the
action was performed on the logical database and the values of the output arguments
returned. For example, the transaction state
BR
Œx
1
;
v
1
W Œx
1
;
v
1
;2
v
1
represents the result of performing the first three actions of the transaction given
in Example
1.1
. The arguments x
1
and
v
1
are constants; RŒx
1
;
v
1
represents a read
action that, when given input x
1
, retrieved from the database the tuple .x
1
;
v
1
/l; and
WŒx
1
;
v
1
;2
v
1
represents an update action that, when given input x
1
, returned the
value
v
1
of the tuple with key x
1
and replaced the value in the tuple by the value 2
v
1
.
We use the symbol T (or subscripted, T
i
) to denote both the transaction identifier
and the transaction .T; ˛/ as a whole; accordingly, we may say that transaction T
is at state ˛. Also, when the state of the transaction is the interesting part, we may
even talk about “transaction ˛.”
We distinguish between four different types of transaction states: (1) forward-
rolling, (2) committed, (3) backward-rolling, and (4) rolled back. Every transaction
starts as a
forward-rolling transaction
; in general, the state of such a transaction is
an action sequence of the form
B˛;
(1.1)
where B is the
begin-transaction
action and ˛ is a sequence of read actions and
normal (forward-rolling) update actions. The action sequence ˛ forms the
forward-
rolling phase
of the transaction.
The begin-transaction action can be thought of as an action that is needed to
introduce a new transaction into the system, including the generation of a new
transaction identifier. We assume that with database interfaces such as (embedded)
