Chapter 5

Transaction & Concurrency

Control
 5.1 The Concept of 'Transaction'
• A transaction is the basic logical unit of execution
in an information system
• A transaction is a sequence of operations that
must be executed as a whole

ACCOUNT A ACCOUNT B
transfer $500
XYZ PQR
$1000 $0
1. Debit A
2. Credit B

 The database system must ensure that either

(1) and (2) happen or that neither happens.
Otherwise inconsistency occurs
Requirements for Database Consistency

Concurrency Control

The simultaneous execution of many

different application programs must
be such that each transaction does
not interfere with another transaction.

The concurrent execution of

transactions must be such that each
transaction appears to execute in
isolation.
 Properties of Transactions (ACID)
• Atomicity: a transaction is an atomic unit of processing and it is
either performed entirely or not at all

• Consistency Preservation: a transaction's correct execution must

take the database from one correct state to another

• Isolation: the updates of a transaction must not be made visible to

other transactions until it is committed (solves the temporary update
problem)

• Durability or Permanency: if a transaction changes the database

and is committed, the changes must never be lost because of
subsequent failure

• Serializability: transactions are considered serializable if the effect

of running them in an interleaved fashion is equivalent to running
them serially in some order
Transaction as a Concurrency Unit
 Transactions must be synchronised correctly to guarantee
database consistency
T1 simultaneous T2

ACCOUNT A transfer £500 ACCOUNT B transfer £300 ACCOUNT C

Ramesh Rajesh Amit
1. Debit A 1. Debit B
£1000 £0 2. Credit C £200
2. Credit B

Net Result
ACCOUNT A ACCOUNT B ACCOUNT C
Ramesh Rajesh Amit
£500 £200 £500
Concurrency in Transaction Execution

• Most DBMS are multi-user systems

• There is a need to ensure that concurrent transactions
do not interfere with each others operations
• Transaction scheduling algorithms

Transaction Serializability

The effect on a database of any number of

transactions executing in parallel must be the
same as if they were executed one after another
• Different operations of Transaction:
• RT(O) Denotes the Transaction ‘T’ Reading on
Object ‘O’.
• WT(O) Denotes the Transaction ‘T’ Writing on
Object ‘O’.
• AbortT Denotes the Transaction ‘T’ being
aborted.
• CommitT Denotes the Transaction ‘T’ has been
Committed.
 Schedules of Transactions

• A schedule S of n transactions is a sequential ordering of

the operations of the n transactions.

• A schedule maintains the order of operations within the

individual transaction. It is subject to the constraint that
for each transaction T participating in S, if operation i is
performed in T before operation j, then operation i will be
performed before operation j in S.

• The Serializability theory attempts to determine the

'correctness' of the schedules.
 Serial, Nonserial and Serializable
Schedules
• A schedule S is serial if, for every transaction T participating
in S all of T's operations are executed consecutively in the
schedule; otherwise it is called nonserial.

• A schedule S of n transactions is serializable if it is equivalent

to some serial schedule of the same n transactions.
Example of Serial Schedules
Schedule A

T1: T2:
read_item(x)
X:= X - N;
write_item(X);
read_item(Y);
time Y:=Y + N;
write_item(Y);
read_item(X);
X:= X + M;
write_item(X);
Example of Nonserial Schedules
Schedule A

T1: T2:
read_item(X);

X:= X - N;

read_item(X);
time
X:= X + M;
write_item(X);
read_item(Y);

write_item(X);
Y:=Y + N;
write_item(Y);
 5.2 Methods for Serializability
• Protocols that, if followed by every transaction, will ensure
serializability of all schedules in which the transactions
participate. They may use locking techniques of data items
to prevent multiple transactions from accessing items
concurrently.

• Timestamps are unique identifiers for each transaction and

are generated by the system. Transactions can then be
ordered according to their timestamps to ensure
serializability.

• Multiversion Concurrency Control Techniques keep the old

values of a data item when that item is updated.
 5.3 States of Transaction
• Active: The initial state; the transaction stays in this state while
it is executing.
• Partially committed: After the final statement has been
executed.
• Failed: After the discovery that normal execution can no longer
proceed.
• Aborted: After the transaction has been rolled back and the
database restored to its state prior to the start of the transaction.
• Two options after it has been aborted:
– Restart the transaction – only if no internal logical error.
– Kill the transaction.
• Committed: After successful completion.
Transaction States

Partially
Committed
Committed

Active

Failed Aborted
5.3.1 Locking Techniques for
Concurrency Control
• The concept of locking data items is one of the main
techniques used for controlling the concurrent execution of
transactions.

• A lock is a variable associated with a data item in the

database. Generally there is a lock for each data item in the
database.

• A lock describes the status of the data item with respect to

possible operations that can be applied to that item. It is
used for synchronising the access by concurrent
transactions to the database items.
 to ensure that, even though actions of several
transactions might be interleaved, the net effect is
identical to executing all transactions in some serial
order.
• Transactions might be interleaved, the net effect is
identical to executing all transactions in some serial
order.
• Different locking protocols use different types of
locks.
• There are ‘2’ types of lock modes in which a data
item may be locked.
• Lock Modes:
• Exclusive Lock (X):
• It is also called as an update or write lock. The intension of this
mode of locking is to provide exclusive use of the data item to one
transaction.
• If a transaction ‘T’ locks a data item ‘Q’ in an exclusive mode, no
other transaction can access ‘Q’, not even to read ‘Q’, until the lock
is released by transaction ‘T’.

• Shared Lock (S):

It is also called a read lock. The intension of this mode of locking is
to ensure that the data item does not undergo any modifications
while it is locked in this mode.
 Types of Locks

• Binary (Exclusive) locks have two possible states: locked

(lock_item(X) operation) and unlocked (unlock_item(X)
operation

• Multiple-mode (Shared) locks allow concurrent access to

the same item by several transactions. They have three
possible states: read locked or shared locked (other
transactions are allowed to read the item) write locked or
exclusive locked (a single transaction exclusively holds the
lock on the item) and unlocked.
Two-Phase Locking
• All locking operations (read_lock, write_lock) precede
the first unlock operation in the transactions. Two
phases:

1.Expanding phase: new locks on items can be acquired

but none can be released

2. Shrinking phase: existing locks can be released but no

new ones can be acquired
not two-phase two-phase locking
locking

read_lock(Y); read_lock(X);
read_lock(X);
read_item(X);
read_item(Y);

unlock(Y); write_lock(Y);
read_item(X);
unlock(X);
X:=X+Y;
read_item(Y);
write_lock(X);
write_item(X); Y:=X+Y;
write_item(Y);

unlock(Y);
unlock(X);
 Locking Problems
• Deadlock: when each of two transactions is waiting for the
other to release an item.

• Approaches for solution:

– deadlock prevention protocol: every transaction must
lock all items it needs in advance
– deadlock detection (if the transaction load is light or
transactions are short and lock only a few items):

• Livelock: a transaction cannot proceed for an indefinite

period of time while other transactions in the system
continue normally.
– Solution: fair waiting schemes (i.e. first-come-first-
served)
5.3.2 Timestamp-Based Protocols
• Each transaction is issued a timestamp when it enters the system. If an
old transaction Ti has time-stamp TS(Ti), a new transaction Tj is assigned
time-stamp TS(Tj) such that TS(Ti) <TS(Tj).
• The protocol manages concurrent execution such that the time-stamps
determine the serializability order.
• In order to assure such behavior, the protocol maintains for each data Q
two timestamp values:
– W-timestamp(Q) is the largest time-stamp of any transaction that
executed write(Q) successfully.
– R-timestamp(Q) is the largest time-stamp of any transaction that
executed read(Q) successfully.
 (Cont.)
• The timestamp ordering protocol ensures that any conflicting read
and write operations are executed in timestamp order.

• Suppose a transaction Ti issues a read(Q)

1. If TS(Ti)  W-timestamp(Q), then Ti needs to read a value of Q
that was already overwritten.
 Hence, the read operation is rejected, and Ti is rolled back.

2. If TS(Ti) W-timestamp(Q), then the read operation is executed,

and R-timestamp(Q) is set to max(R-timestamp(Q), TS(Ti)).
 (Cont.)
• Suppose that transaction Ti issues write(Q).
1. If TS(Ti) < R-timestamp(Q), then the value of Q that Ti is producing was
needed previously, and the system assumed that that value would never
be produced.
 Hence, the write operation is rejected, and Ti is rolled back.
2. If TS(Ti) < W-timestamp(Q), then Ti is attempting to write an obsolete
value of Q.
 Hence, this write operation is rejected, and Ti is rolled back.
3. Otherwise, the write operation is executed, and W-timestamp(Q) is set
to TS(Ti).
Example Use of the Protocol
A partial schedule for several data items for transactions
with
timestamps 1, 2, 3, 4, 5
T1 T2 T3 T4 T5
read(X)
read(Y)
read(Y)
write(Y)
write(Z)
read(Z)
read(X)
abort
read(X)
write(Z)
abort
write(Y)
write(Z)
Correctness of Timestamp-Ordering Protocol

• The timestamp-ordering protocol guarantees

serializability since all the arcs in the precedence
graph are of the form:

transaction transaction
with smaller with larger
timestamp timestamp

Thus, there will be no cycles in the precedence graph

• Timestamp protocol ensures freedom from deadlock
as no transaction ever waits.
• But the schedule may not be cascade-free, and may
not even be recoverable.
5.3.3 Granularity of Data Items
• It refers to the size of data items: fine granularity for
small item sizes, coarse granularity for large item
sizes. Sizes:
– a database record
– a field value of a database record
– a disk block
– a whole file
– the whole database

• If a typical transaction accesses a small number of

records it is advantageous that the data item
granularity is one record. If a transaction typically
accesses many records of the same file it is better to
have block or file granularity so that the transaction
will consider all those records as one data item.
 Granularity of Items (continued)
• As finer data granularity, as higher locking overhead of the
DBMS lock manager (due to many locks and unlocks)
• The best item size depends on the type of a transaction:
– If a transaction accesses a small number of records, than
data item = record
– If a transaction accesses a large number of records in the
same file, then
data item = file
– Some DBMS automatically change granularity level with
regard to the number of records a transaction is accessing
(attempting to lock)
5.3.4 Dead Lock

• Dead lock is also called deadly embrace

• Typical sequence of operations is given on the following
diagram

T1 T2
T1 acquired exclusive
write_lock(X )
lock on X
write_lock(Y ) T2 acquired exclusive
t lock on Y
write_lock(Y ) i No one can finish,
m because both are in
write_lock(X ) the waiting state
e
Dead Lock (continued)

• Dead lock occurs when:

– Each transaction Ti in a set of two or more transactions
T = {T1, T2, …, Tn } of a schedule S is waiting for some
item X that is locked by some other transaction Tj in S

• In other words:
– A number of transactions (grater than one) hold lock on
one item and wait to acquire another
– No one of the waiting transactions can acquire locks on
all necessary items
 Dead Lock (continued)
• Dead lock examples:
a)
– T1 has locked X and waits to lock Y
– T2 has locked Y and waits to lock Z
– T3 has locked Z and waits to lock X
b)
– BothT1 and T2 have acquired sharable locks on X and wait to
lock X exclusively
• All that results in a cyclic wait for graph
T2 waits for T1

T1 T2

T1 waits for T2
 Dead Lock Prevention Techniques

• There is a number of deadlock prevention techniques

• These are:
– Conservative two phase lock protocol
– Timestamp techniques:
• Wait – Die protocol
• Wound – Wait protocol
– No – Wait protocol
– Cautions – Wait protocol
• There is a number of dead lock detection techniques:
– Dead lock detection using wait-for graph
– Time-out scheme
 Dead Lock Prevention Techniques

• There is a number of deadlock prevention techniques

• These are:
– Conservative two phase lock protocol
– Timestamp techniques:
• Wait – Die protocol
• Wound – Wait protocol
– No – Wait protocol
– Cautions – Wait protocol
• There is a number of dead lock detection techniques:
– Dead lock detection using wait-for graph
– Time-out scheme
 Conservative Two Phase Locking Protocol
• Conservative two phase locking
– A transaction has to lock all items it will access before it
begins to execute (as in the ordinary two phase locking),
– If it cannot acquire any of its locks, it releases all items,
aborts, and tries again,
– Deadlock can't occur because no hold - and wait
– Once it starts, a transaction is always in its shrinking phase

• Problems:
– What if a transaction cannot predetermine all items it is
going to use? (e.g. a sequence of interactive SQL
statements comprising one database transaction)
– What if a database item that is already locked by another
transaction will be released very soon? (i.e. the transaction
is aborted in vane)
 Using Timestamps
• Timestamps are used together with two phase locking
• DBMS assigns a timestamp TS to each transaction T entering the
system
• If Ti starts before Tj , then
TS (Ti ) < TS (Tj) (*Ti is older than Tj )

• WAIT-DIE protocol:
– An older transaction can wait on an item locked by a younger one,
– But a younger one gets killed (aborted and restarted with the
same timestamp) instead of waiting
– Since each transaction involved in a dead lock has a different age,
the dead lock will be prevented
 Using Timestamps (continued)

• WOUND-WAIT protocol:
– If a transaction tries to lock an item held by another
one, the older transaction wound the younger one
(causes abort and restart with the same timestamp),
– But the younger one is allowed to wait
– So, the oldest transaction will be allowed to finish

• Both time stamping schemes abort the younger

transaction that may be involved in a deadlock, although
there is no proof of a deadlock