TEDU – CMPE 232 – Database Systems

• A and B, executing concurrently in an interleaved fashion.

• Interleaving keeps the CPU busy when a process requires an
input or output (I/O) operation, such as reading a block from
disk.
• The CPU is switched to execute another process rather than
remaining idle during I/O time.
• Interleaving also prevents a long process from delaying other
processes.
• A transaction is an executing program that forms a logical unit of
database processing.
• includes one or more database access operations:
• insertion, deletion, modification, or retrieval operations.
• read_item(X).
1. Find the address of the disk block that contains item X.
2. Copy that disk block into a buffer in main memory (if that disk block is not
already in some main memory buffer).
3. Copy item X from the buffer to the program variable named X.
• write_item(X).
1. Find the address of the disk block that contains item X.
2. Copy that disk block into a buffer in main memory (if that disk block is not
already in some main memory buffer).
3. Copy item X from the program variable named X into its correct location in
the buffer.
4. Store the updated block from the buffer back to disk (either immediately
or at some later point in time).
• Interactions among concurrently executing transactions can
cause the database state to become inconsistent.
• Timing of individual steps of different transactions needs to be
regulated in some manner.
• This regulation is the job of the scheduler component of the
DBMS, and the general process of assuring that transactions
preserve consistency when executing simultaneously is called
concurrency control.

• The scheduler takes read/write

requests from transactions and
either executes them in buffers
or delays them
• BEGIN_TRANSACTION
• READ or WRITE
• END_TRANSACTION
• COMMIT_TRANSACTION
• ROLLBACK (or ABORT)
• Oracle REDO and UNDO
• https://www.youtube.com/watch?v=X9mTrflGhvU
• Oracle Architecture
• https://www.youtube.com/watch?v=bt8-QJr8bqA
• The System Log
• Log or Journal: The log keeps track of all transaction operations that
affect the values of database items.
• This information may be needed to permit recovery from transaction
failures.
• The log is kept on disk, so it is not affected by any type of failure
except for disk or catastrophic failure.
• In addition, the log is periodically backed up to archival storage (tape)
to guard against such catastrophic failures.
• The System Log (cont):
• T in the following discussion refers to a unique transaction-id that is
generated automatically by the system and is used to identify each
transaction:
• Types of log record:
• [start_transaction,T]: Records that transaction T has started execution.
• [write_item,T,X,old_value,new_value]: Records that transaction T has
changed the value of database item X from old_value to new_value.
• [read_item,T,X]: Records that transaction T has read the value of
database item X.
• [commit,T]: Records that transaction T has completed successfully, and
affirms that its effect can be committed (recorded permanently) to the
database.
• [abort,T]: Records that transaction T has been aborted.
Recovery using log records:
• If the system crashes, we can recover to a consistent database
state by examining the log and using one of the techniques
described in later slides.
1. Because the log contains a record of every write operation that
changes the value of some database item, it is possible to undo
the effect of these write operations of a transaction T by tracing
backward through the log and resetting all items changed by a
write operation of T to their old_values.
2. We can also redo the effect of the write operations of a
transaction T by tracing forward through the log and setting all
items changed by a write operation of T (that did not get done
permanently) to their new_values.
Commit Point of a Transaction:
• Definition a Commit Point:
• A transaction T reaches its commit point when all its operations that
access the database have been executed successfully and the effect of
all the transaction operations on the database has been recorded in
the log.
• Beyond the commit point, the transaction is said to be committed, and
its effect is assumed to be permanently recorded in the database.
• The transaction then writes an entry [commit,T] into the log.
• Roll Back of transactions:
• Needed for transactions that have a [start_transaction,T] entry into the
log but no commit entry [commit,T] into the log.
Commit Point of a Transaction (cont):
• Redoing transactions:
• Transactions that have written their commit entry in the log must also
have recorded all their write operations in the log; otherwise, they
would not be committed, so their effect on the database can be
redone from the log entries. Notice that the log file must be kept on
disk.
• At the time of a system crash, only the log entries that have been
written back to disk are considered in the recovery process because
the contents of main memory may be lost.
• Force writing a log:
• Before a transaction reaches its commit point, any portion of the log
that has not been written to the disk yet must now be written to the
disk.
• This process is called force-writing the log file before committing a
transaction
• “Correctness Principle” : every transaction, if executed in
isolation (without any other transactions running concurrently),
will transform any consistent state to another consistent state.
• In practice, transactions often run concurrently with other
transactions, so the correctness principle doesn’t apply directly.
• This section introduces the notion of “schedules,” the sequence of
actions performed by transactions and “serializable schedules,”
which produce the same result as if the transactions executed
one-at-a-time.
• A schedule is a sequence of the important actions taken by one or
more transactions.
• When studying concurrency control, the important read and write
actions take place in the main-memory buffers, not the disk.
• That is, a database element A that is brought to a buffer by some
transaction T may be read or written in that buffer not only by T but
by other transactions that access A.
• Let us consider two transactions and the effect on the
database when their actions are executed in certain
orders. The important actions of the transactions T1
and T2 are shown in Fig. The variables t and s are
local variables of T1 and T2, respectively; they are
not database elements. We shall assume that the
only consistency constraint on the database state is
that A = B. Since T1 adds 100 to both A and B , and
T2 multiplies both A and B by 2, we know that each
transaction, run in isolation, will preserve
consistency.
 • A schedule is serial if its actions consist of all the actions of one
transaction, then all the actions of another transaction, and so
on. No mixing of the actions is allowed.
• In general, we would not expect the final state
of a database to be independent of the order of transactions.

Serial schedule in which T1 precedes T2 Serial schedule in which T2 precedes T1

• Are there any other schedules that also are guaranteed to
preserve consistency?
• In general, we say a schedule S is serializable if there is a serial
schedule S' such that for every initial database state, the effects
of S and S‘ are the same.

A serializable, but not serial, schedule A nonserializable schedule

• To make the notation precise:
• An action is an expression of the form ri(X )
or wi(X), meaning that transaction Ti reads
or writes, respectively, the database
element X .
• A transaction Ti is a sequence of actions
with subscript i.
• A schedule S of a set of transactions T is a
sequence of actions, in which for each
transaction Ti in ƒ, the actions of Ti appear
in S in the same order that they appear in
the definition of Tj itself. We say that S is
an interleaving of the actions of the
transactions of which it is composed.
• Schedulers in commercial systems generally enforce a condition,
called “conflict serializability,” that is stronger than the general notion
of serializability.
• It is based on the idea of a conflict: a pair of consecutive
actions in a schedule such that, if their order is interchanged, then the
behavior of at least one of the transactions involved can change.
• To begin, let us observe that most pairs of actions do not conflict. In
what follows, we assume that Ti , and TJ are different transactions; i.e.,
i != J.
• ri (X); rJ(Y) is never a conflict,
• ri(X); wJ(Y) is not a conflict provided X != Y.
• wi(X); rJ(Y) is not a conflict if X != Y,
• wi(X); wJ(Y) is not a conflict as long as X != Y.
• There are three situations where we may not swap the order
of actions:
• ri(X); wi(Y), always conflict.
• wi(X); wJ(X) is a conflict.
• ri(X); wJ(X) is a conflict, and so is wi(X); rJ(X).
• The conclusion we draw is that any two actions of different transactions
may be swapped unless:
• They involve the same database element, and
• At least one is a write.
• We may take any schedule and make as many nonconflicting swaps as
we wish, with the goal of turning the schedule into a serial schedule.
• If we can do so, then the original schedule is serializable, because its
effect on the database state remains the same as we perform each of
the nonconflicting swaps.
• We claim this schedule is conflict-serializable. Figure shows the
sequence of swaps in which this schedule is converted to the
serial schedule (T1, T2), where all of T1’s actions precede all
those of T2. We have underlined the pair of adjacent actions
about to be swapped at each step.

Converting a conflict-serializable schedule to a serial schedule by

swaps of adjacent actions
• Testing Conflict Serializability of a Schedule S
• For each transaction Ti participating in schedule S, create a node labeled
Ti in the precedence graph.
• For each case in S where TJ executes a read_item(X) after Ti executes a
write_item(X), create an edge (Ti → TJ) in the precedence graph.
• w i (X), r J (X) → (Ti → TJ)
• For each case in S where TJ executes a write_item(X) after Ti executes a
read_item(X), create an edge (Ti → TJ) in the precedence graph.
• r i (X), w J (X) → (Ti → TJ)
• For each case in S where TJ executes a write_item(X) after Ti executes a
write_item(X), create an edge (Ti → TJ) in the precedence graph.
• w i (X), w J (X) → (Ti → TJ)
• The schedule S is serializable if and only if the precedence graph has no
cycles.
 Examples of serial and nonserial
schedules involving transactions T1
and T2. (a) Serial schedule A: T1
followed by T2. (b) Serial schedule
B: T2 followed by T1.
(c) Two nonserial schedules C and D
with interleaving of operations.

Constructing the precedence graphs for schedules

A to D from Figure to test for conflict
serializability. (a) Precedence graph for serial
schedule A. (b) Precedence graph for serial
schedule B. (c) Precedence graph for schedule C
(not serializable). (d) Precedence graph for
schedule D (serializable, equivalent to schedule A).
• For the following schedule:
• What is the precedence graph for the schedule?
• Is the schedule conflict-serializable? If so, what are all the equivalent
serial schedules?

• The precedence graph is:

• T3 -----> T2 -----> T1
• The schedule is thus conflict-serializable. The only conflict-equivalent serial
schedule is (T3, T2, T1).
• Transactions, Schedules, Serial and Serializable Schedules
• We may take any schedule and make as many nonconflicting
swaps as we wish, with the goal of turning the schedule into a
serial schedule.
• They involve the same database element, and
• At least one is a write.
• Precedence Graph
• w i (X), r J (X) → (Ti → TJ)
• r i (X), w J (X) → (Ti → TJ)
• w i (X), w J (X) → (Ti → TJ)
• S = r1 (X); r2 (Z); r1 (Z); r3 (X); r3 (Y); w1 (X); c1; w3 (Y); c3; r2 (Y); w2 (Z); w2 (Y);
c2;
• Recoverable?
• TJ commits after Ti if TJ has read any data item written by Ti.
• Note : Ci > C J means Ci happens before C J. Ai denotes abort Ti. To test if
a schedule is recoverable one has to include abort operations. Thus in
testing the recoverability, abort operations will have to be used in place
of commit one at a time. Also the strictest condition is where a transaction
neither reads nor writes to a data item, which was written to by a
transaction that has not committed yet.
• If A1>C3>C2, then S is recoverable because rolling back of T1 does not
affect T2 and T3.
• If C1>A3>C2, S is not recoverable because T2 read the value of Y (r2 (Y))
after T3 wrote Y (w3 (Y)) and T2 committed but T3 rolled back. Thus, T2
used non- existent value of Y.
• If C1>C 3 >A 2, then S is recoverable because roll back of T2 does not
affect T1 and T3. Strictest condition of S is C3>C2.
• “Locks” are maintained on database elements to prevent
unserializable behavior.
• Intuitively, a transaction obtains locks on the database elements
it accesses to prevent other transactions from accessing these
elements at roughly the same time and thereby incurring the risk
of unserializability.
• In Fig. Below we see a scheduler that uses a lock table to help
perform its job.
• Responsibility of the scheduler is to take requests from
transactions and either allow them to operate on the database
or block the transaction until such time as it is safe to allow it to
continue.
• A lock table will be used to guide this decision.
• li(X): Transaction Ti requests a lock on database element X .
• ui(X): Transaction Ti releases (“unlocks”) its lock on database
element X.
• The consistency condition for transactions can be stated as:
“Whenever a transaction Ti has an action ri(X) or wi(X), then
there is a previous action li(X) with no intervening action ui(X),
and there is a subsequent ui(X).”
• The legality of schedules is stated: “If there are actions li(X)
followed by lJ(X) in a schedule, then somewhere between these
actions there must be an action ui(X).
• The schedule is legal because the two transactions never hold a
lock on A at the same time, and likewise for B.
• Specifically, T2 does not execute l2(A) until after T1 executes
u1(A), and T1 does not execute l1(B) until after T2 executes u2(B).
• As we see from the trace of the values computed, the schedule,
although legal, is not serializable.
• Here are T1 and T2 from same example, with simple but important changes, in
which T1 and T2 each lock B before releasing the lock on A.
• When T2 requests a lock on B, the scheduler must deny the lock, because T1
still holds a lock on B. Thus, T2 is delayed, and the next actions are from T1.

Eventually, T1 executes u1(A), which

unlocks B. Now, T2 can get its lock
on B, which is executed at the next
step. Notice that because T2 was
forced to wait, it wound up
multiplying B by 2 after T1 added
100, resulting in a consistent
database state.
• A transaction is said to follow the two-phase locking protocol
if all locking operations (read_lock, write_lock) precede the
first unlock operation in the transaction.
• Such a transaction can be divided into two phases:
• an expanding or growing (first) phase, during which new locks on items
can be acquired but none can be released;
• and a shrinking (second) phase, during which existing locks can be
released but no new locks can be acquired.
• The main problem is that a transaction T must take a lock on a
database element X even if it only wants to read X and not write it.
• We cannot avoid taking the lock, because if we didn’t, then another
transaction might write a new value for X while T was active and
cause unserializable behavior.
• On the other hand, there is no reason why several transactions
could not read X at the same time, as long as none is allowed to
write X .
• The most common locking scheme, where there are two different
kinds of locks,
• one for reading (called a “shared lock” or “read lock”),
• and one for writing (called an “exclusive lock” or “write lock”).
• For any database element X there can be either one exclusive
lock on X, or no exclusive locks but any number of shared locks.
• If we want to write X , we need to have an exclusive lock on X,
but if we wish only to read X we may have either a shared or
exclusive lock on X.
• If we want to read X but not write it, it is better to take only a
shared lock.
• We shall use sli(X) to mean “transaction Ti requests a shared
lock on database element X ” and xli(X) for “Ti requests an
exclusive lock on X.”
• We continue to use ui(X) to mean that Ti unlocks X; i.e., it
relinquishes whatever lock(s) it has on X .
• The three kinds of requirements - consistency and 2PL for transactions,
and legality for schedules - each have their counterpart for a
shared/exclusive lock system.
• Consistency of transactions:
• A read action ri(X) must be preceded by sli(X) or xli(X), with no intervening
ui(X).
• A write action wi(X) must be preceded by xli(X), with no intervening ui(X). All
locks must be followed by an unlock of the same element.
• Two-phase locking of transactions: Locking must precede unlocking. To be more
precise, in any two-phase locked transaction Ti, no action sli(X) or xli(X) can be
preceded by an action ui(Y), for any Y.
• Legality of schedules: An element may either be locked exclusively by one
transaction or by several in shared mode, but not both. More precisely:
• If xli(X) appears in a schedule, then there cannot be a following xlJ(X) or
slJ(X), for some J other than i, without an intervening ui(X).
• If sli(X) appears in a schedule, then there cannot be a following xlJ(X), for J
!= i, without an intervening ui(X).
• Both T1 and T2 read A and B, but only T1 writes B. Neither writes A.
• In Fig. below is an interleaving of the actions of T1 and T2 in which
T1 begins by getting a shared lock on A.
• Then, T2 follows by getting shared locks on both A and B. Now, T1
needs an exclusive lock on B, since it will both read and write B.

• However, it cannot get the

exclusive lock because T2 already
has a shared lock on B.
• Thus, the scheduler forces T1 to
wait.
• Eventually, T2 releases the lock on
B. At that time, T1 may complete.
• If we use several lock modes, then the scheduler needs a policy
about when it can grant a lock request, given the other locks
that may already be held on the same database element.
• A compatibility matrix is a convenient way to describe
lock-management policies.
• Deadlock occurs when each transaction T in a set of two or more
transactions is waiting for some item that is locked by some
other transaction T’ in the set.
• Hence, each transaction in the set is in a waiting queue, waiting
for one of the other transactions in the set to release the lock on
an item.
• But because the other transaction is also waiting, it will never
release the lock.
• The simplest way to detect and resolve deadlocks is with a
timeout. Put a limit on how long a transaction may be active,
and if a transaction exceeds this time, roll it back.
• For example, in a simple transaction system, where typical
transactions execute in milliseconds, a timeout of one minute
would affect only transactions that are caught in a deadlock.
• Deadlocks that are caused by transactions waiting for locks
held by another can be detected by a waits-for graph,
indicating which transactions are waiting for locks held by
another transaction.
• This graph can be used either to detect deadlocks after they
have formed or to prevent deadlocks from ever forming.
• The waits-for graph has a node for each transaction that
currently holds any lock or is waiting for one. There is an arc
from node (transaction) T to node U if there is some database
element
• A such that:
• U holds a lock on A,
• T is waiting for a lock on A, and
• T cannot get a lock on A in its desired mode unless U first releases its
lock on A
• If there are no cycles in the waits-for graph, then each
transaction can complete eventually.
•

Waits-for Waits-for graph with a

graph after cycle caused by step
step (7) (8)
• An alternative to maintaining the waits-for graph is to associate
with each transaction a timestamp.
• The timestamp is used when a transaction T has to wait for a
lock that is held by another transaction U.
• Two different things happen, depending on whether T or U is
older (has the earlier timestamp).
• There are two different policies that can be used to manage
transactions and detect deadlocks.
• The Wait-Die Scheme:
• If T is older than U (i.e., the timestamp of T is smaller than U’s timestamp),
then T is allowed to wait for the lock(s) held by U.
• If U is older than T, then T “dies”; it is rolled back.
• The Wound-Wait Scheme:
• If T is older than U, it “wounds” U. Usually, the “wound” is fatal: U must roll
back and relinquish to T the lock(s) that T needs from U. There is an
exception if, by the time the “wound” takes effect, U has already finished
and released its locks. In that case, U survives and need not be rolled
back.
• If U is older than T, then T waits for the lock(s) held by U.
• THE END