DATABASE

SYSTEM PRINCIPLES
TRANSACTION MANAGEMENT

A/P Sourav S Bhowmick

PROPERTIES OF TRANSACTIONS

a c i d
Atomicity: Consistency: Isolation: Durability:
Transactions Only valid Transactions Written
are all or data is do not data will not
nothing saved affect each be lost
other
ISOLATION

Motivation

• Multiple transactions are running concurrently T1, T2, …

• They read/write some common elements A1, A2, …
• DB state can be inconsistent even if T1, T2… individually
preserves correctness of the state & no system failure

Why insist on isolation?

• Maintaining the interconsistency of transactions
• If two concurrent transactions access a data item that is
being updated by one of them, it is not possible to
guarantee that the second will read the correct value
 CONCURRENT TRANSACTIONS

T1 Seq of Exec.
x= 50
READ(x) T1: READ(x)
x := x+1 T1: x := x+1
WRITE(x) T1: WRITE(x)
Commit T1: Commit
T2: READ(x)
T2: x := x+1
T2: WRITE(x)
T2
T2: Commit
READ(x)
x := x+1
WRITE(x)
Commit
 CONCURRENT TRANSACTIONS

T1 Seq of Exec.
x= 50 Ensure isolation by not
READ(x) T1: READ(x) permitting incomplete
x := x+1 T1: x := x+1 results to be seen by
WRITE(x) T2: READ(x) other transactions
Commit T1: WRITE(x)
T2: x := x+1
T2: WRITE(x)
T1: Commit
T2
T2: Commit
READ(x)
x := x+1
WRITE(x) • T2 reads 50
Commit • Value of x is 51 at the
end of T1 and T2 since
T2’s WRITE overwrites
T1’s WRITE
 CONCURRENT TRANSACTIONS

• If a transaction permits others to

T1 Seq of Exec. see its incomplete results before
x= 50
READ(x) T1: READ(x) committing and then decide to
x := x+1 T1: x := x+1 abort, any transaction that has
WRITE(x) T1: WRITE(x) read its incomplete values will
Commit T2: READ(x) have to be abort as well
T2: x := x+1 • Considerable overhead on DBMS
T2: WRITE(x)
T1: ABORT
T2
T2: Commit
READ(x)
x := x+1
WRITE(x) • T2 has read
Commit incomplete
value
KEY QUESTION

ONE-PASS ALGORITHMS

How do we ensure consistency during

concurrent execution of transactions?

• Concurrency Control
CONCURRENCY CONTROL

Concurrency Control

The process of assuring that transactions preserve

consistency when executing simultaneously

Who is responsible?

• Scheduler of the DBMS

What could go wrong if we don’t have it?

• Dirty reads (including inconsistent reads),

Unrepeatable reads, Lost updates
DIRTY READ & INCONSISTENT READ
T1 T2
• WRITE(A)

• READ(A)
• ABORT(A)

Dirty Read

T1 T2
A := 20; B := 20;
WRITE(A)
READ(A)
READ(B)
WRITE(B)

Inconsistent Read
UNREPEATABLE READ & LOST UPDATE
T1 T2
READ(A)

WRITE(A)
READ(A)

Unrepeatable Read

T1 T2
READ(A)
READ(A)
A:= A + 5
A:= A* 1.3
WRITE(A)
WRITE(A);
Lost Update
 UNREPEATABLE READ & LOST UPDATE
Lost Update Model

Write
Acquire Debit
User 1 record to
Customer Account
Customer
Record for $400
table.
Bal = $500 Bal = $100
Bal = $100

Time
Write
Acquire Credit
record to
User 2 Customer Account
Customer
Record for $200
table.
Bal = $500 Bal = $700
Bal = $700

The $200 credit transaction is lost.

Ending balance should be $300.
SOLUTION: SERIALIZABILITY

T1
READ(x)
x := x+1
WRITE(x) If the concurrent
Commit execution of transactions
leave the database in a
state that can be
achieved by their serial
T2 execution in some order,
READ(x) then problem solved!
x := x+1
WRITE(x)
Commit

Serial execution of a set of transactions maintains the

consistency of the DB
SCHEDULE
What is it?

Given multiple transactions, a schedule is a sequence of

interleaved actions from all transactions

T1 T2
DB consistent state:
READ(A, t) READ(A, s) A=B
t := t+100 s := s*2
WRITE(A, t) WRITE(A, s)
READ(B, t) READ(B, s)
t := t+100 s := s*2
WRITE(B, t) WRITE(B, s)
 SERIAL SCHEDULE

T1 T2 A B
25 25
What is it?
READ(A, t)
t := t+100
A schedule is serial if its actions
consists of all the actions of one WRITE(A, t) 125
transaction, then all the actions READ(B, t)
of another transaction, and so on
t := t+100
WRITE(B, t) 125
Final state is not independent of READ(A, s)
the order of transactions s := s*2
WRITE(A, s) 250
READ(B, s)
s := s*2
WRITE(B, s) 250
 SERIALIZABLE SCHEDULE
T1 T2 A B
Motivation 25 25
READ(A, t)
• Every serial schedule will t := t+100
preserve DB consistency
WRITE(A, t) 125
• Are there any other schedules
that also are guaranteed to READ(A, s)
preserve consistency? s := s*2
WRITE(A, s) 250
Serializable Schedule READ(B, t) Not serial but
t := t+100 the effect is
A schedule is serializable if it is WRITE(B, t) the same 125
equivalent to a serial schedule
READ(B, s)
s := s*2
WRITE(B, s) 250
A NON-SERIALIZABLE SCHEDULE
T1 T2 A B
25 25
This sort of behaviour
READ(A, t)
that concurrency
control mechanism
t := t+100
must avoid!
WRITE(A, t) 125
READ(A, s)
s := s*2
WRITE(A, s) 250
READ(B, s)
s := s*2
WRITE(B, s) 50
READ(B, t)
t := t+100
WRITE(B, t) 150
IGNORE TRANSACTION SEMANTICS

Avoid unrealism

• Scheduler should not look at transaction details

Assumption

• Assume worst case updates

• Only care about read r(A) and write w(A)
• Not the actual values involved
 NOTATIONS

T1
READ(A, t)
t := t+100
WRITE(A, t)
READ(B, t)
T1: r1(A); w1(A); r1(B); w1(B)
t := t+100
WRITE(B, t)
T2
READ(A, s)
s := s*2
WRITE(A, s)
T2: r2(A); w2(A); r2(B); w2(B) READ(B, s)
s := s*2
WRITE(B, s)
CONFLICT-SERIALIZABILITY

Commercial systems

• Schedulers in commercial systems enforce a

condition called conflict serializability
• Stronger than general notion of serializability
• Based on the idea of a conflicts

Conflict

• Two operations accessing the same database

element x are in conflict if at least one of them is a
write operation
CONFLICT

Implication 1

• Read operations do not conflict with each other

• Two types of conflicts: read-write (write-read) and
write-write

Implication 2

• Two operations can belong to the same transaction

or two different transactions
• For latter case, two transactions are said to be
conflicting

Impact of conflicting actions

• 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
CONFLICTS
No Conflicts Conflicts

Two actions by
ri(X); rj(Y) same transactions
ri(X); wi(Y)

ri(X); wj(Y) for X != Y Two writes by Ti, Tj

to same element
wi(X); wj(X)
wi(X); rj(Y) for X != Y

Read/write by Ti, Tj
wi(X); wj(Y) for X != Y to same element
wi(X); rj(X)
ri(X); wj(X)
CONFLICT-SERIALIZABILITY

Conflict-Serializable

A schedule is conflict serializable if it can be

transformed into a serial schedule by a series of
swappings of adjacent non-conflicting actions.

r1(A); w1(A); r2(A); w2(A); r1(B); w1(B); r2(B); w2(B);

r1(A); w1(A); r2(A); r1(B); w2(A); w1(B); r2(B); w2(B);

r1(A); w1(A); r1(B); r2(A); w2(A); w1(B); r2(B); w2(B);

r1(A); w1(A); r1(B); r2(A); w1(B); w2(A); r2(B); w2(B);

r1(A); w1(A); r1(B); w1(B); r2(A); w2(A); r2(B); w2(B);

THE PRECEDENCE GRAPH TEST

How to Test?

Is a schedule conflict-serializable ?

Precedence Condition

Given a schedule S, T1 takes precedence over T2 (T1 <S T2), if

there are actions A1 of T1 and A2 of T2, such that:
1. A1 is ahead of A2 in S
2. Both A1 and A2 involve the same database element; and
3. At least one of A1 and A2 is a write-action

Precedence Graph
These are exactly the
Summarize the precedence conditions under which
using precendence graph we cannot swap A1 and A2
THE PRECEDENCE GRAPH TEST

Precedence Graph

• Nodes are transactions

• There is an edge from node Ti to Tj if Ti <S Tj
• The test: if the graph has no cycles, then it is conflict
serializable

S: r2(A); r1(B); w2(A); r3(A); w1(B); w3(A); r2(B); w2(B);

1 2 3
Conflict serializable
T1 <S T2

1. A1 is ahead of A2 in S
2. Both A1 and A2 involve the same database element;
and
3. At least one of A1 and A2 is a write-action
PRECENDENCE GRAPH

S: r2(A); r1(B); w2(A); r2(B); r3(A); w1(B); w3(A); w2(B);

1 2 3
Not conflict serializable

T1 <S T2

1. A1 is ahead of A2 in S
2. Both A1 and A2 involve the same database
element; and
3. At least one of A1 and A2 is a write-action
CONFLICT-SERIALIZABILITY

Conflict-Serializability is not necessary for Serializability

A serializable schedule need not be conflict-serializable,

even under the “worst case update” assumption

S1: w1(Y); w1(X); w2(Y); w2(X); w3(X); Cannot convert S2

to a serial schedule
S2: w1(Y); w2(Y); w2(X); w1(X); w3(X); by swaps

• X has the same value after either S1 or S2

• Y has the same value after either S1 or S2
• S1 is serial
• S2 is serializable but not conflict-serializable
PRIMARY FUNCTION OF SCHEDULER

Generate a conflict-serializable
schedule for the execution of pending
transactions

Algorithms

Devise algorithms that are guaranteed to generate

only conflict-serializable schedule
CONCURRENCY CONTROL MECHANISMS
• Assumes many • Not too many transactions
transactions will conflict will conflict with one
with one another. another.
• Synchronizes the • Delay the synchronization
concurrent execution of until their terminations.
transactions early in their
execution life cycle.
Concurrency
Control Algos

Pessimistic Optimistic

Timestamp Timestamp
Locking Hybrid Locking
Ordering Ordering

• Mutually • Locking with Timestamp. • Order the execution of

exclusive access • Not used in commercial transactions according
to shared data. database management to a set of rules.
systems (DBMS).
PESSIMISTIC VS OPTIMISTIC
LOCKS

Locking-based concurrency control

• Ensure that a data item that is shared by conflicting
operations is accessed by one operation at a time.

The idea of locking

• Each element has a unique lock.
• Each transaction must first acquire the lock before
reading/ writing that element.
• If the lock is taken by another transaction, then wait.
• The transaction must release the lock(s).
LOCKS

.
CHARACTERISTICS OF LOCKS

Consistency of Transactions
• A transaction can only read or write an element if it
previously was granted a lock on that element and
hasn’t released the lock yet.
• If a transaction locks an element, it must later
unlock that element.

Legality of Schedules
• No two transactions may have locked the same
element without one having first released the lock.

Notation
li(A) = transaction Ti acquires lock for element A
ui(A) = transaction Ti releases lock for element A
EXAMPLE
T1 T2 A B
Legal schedule as T1 and
25 25 T2 never hold a lock on
l1(A), r1(A); A or B at the same time.
A := A+100
But not serializable!
w1(A), u1(A); 125
l2(A); r2(A);
A := A*2
w2(A); u2(A); 250
l2(B); r2(B);
B := B*2
w2(B); u2(B); 50
l1(B), r1(B);
B := B+100
w1(B), u1(B); 150
ISSUE

How can locking be used to

maintain conflict-serializability?
MAINTAINING CONFLICT-SERIALIZABILITY
T1 T2 A B
Forcing T2 to wait results in
25 25
consistent DB.
l1(A), r1(A);
A := A+100
How can we guarantee a
w1(A); l1(B); u1(A); 125
legal schedule of
l2(A); r2(A); consistent transactions is
A := A*2 conflict-serializable?
w2(A); 250
l2(B) DENIED
r1(B);
B := B+100
w1(B), u1(B); 125
l2(B); u2(A); r2(B);

B := B*2
w2(B); u2(B); 250
 TWO-PHASE LOCKING (2PL)

2PL Rule
In every transaction, all lock actions precede all unlock
actions.

Two phases
• First phase – Locks are obtained.
• Second phase – Locks are relinquished.
• A transaction that obeys 2PL condition is called a
two-phase-locked transaction (2PL transaction).
EXAMPLE
T1 T2 A B Does not obey 2PL condition.
25 25
l1(A), r1(A);
A := A+100
w1(A), u1(A); 125
l2(A); r2(A);
A := A*2
w2(A); u2(A); 250
l2(B); r2(B);
B := B*2
w2(B); u2(B); 50
l1(B), r1(B);
B := B+100
w1(B), u1(B); 150
2PL TRANSACTIONS
T1 T2 A B
l1(A), r1(A);
A := A+100
w1(A); l1(B); u1(A); 125
l2(A); r2(A);
A := A*2
w2(A); 250
l2(B) DENIED
r1(B);
B := B+100
w1(B), u1(B); 125
l2(B); u2(A); r2(B);
B := B*2
w2(B); u2(B); 250
A RISK OF DEADLOCK

T1 T2 A B Not possible to allow both T1 and

25 25 T2 to proceed, since the final DB
state cannot possibly have A = B.
l1(A), r1(A);
l2(B); r2(B);
A : = A+100
B : = B*2
w1(A); 125
w2(B); 50
l1(B) DENIED l2(A) DENIED
A RISK OF DEADLOCK

.
A METAPHOR – ART EXHIBITION

Can we improve these

locking strategies?
 LIMITATIONS

Background
• Too simple to be a practical scheme!
• T must take a lock on a database element X even if it
only wants to read X and not write it.
• No reasons why several transactions can’t read X
at the same time!
REVISIT METAPHOR
LOCK MODES

Types of Locks
• Shared lock (For READ)
• Exclusive lock (For WRITE)
• Update lock
• Initially like shared lock.
• Later may be upgraded to exclusive lock.
 SHARED AND EXLUSIVE LOCKS

Locking scheduler principle

• For any DB 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.
• If we want to read X, we may have a shared or exclusive lock.

Notation
sli(A) = transaction Ti requests a shared lock for element A
xli(A) = transaction Ti requests an exclusive lock for element A
 CHARACTERISTICS OF LOCKS

Consistency of Transactions
• In any transaction Ti, ri(X) must be preceded by sli(X) or
xli(X), with no intervening ui(X).
• In any transaction Ti, wi(X) must be preceded by xli(X),
with no intervening ui(X).

2PL of Transactions
• In any 2PL transaction Ti, no action sli(X) or xli(X) can be
preceded by an action ui(Y), for any Y.
CHARACTERISTICS OF LOCKS

Legality of Schedules
An element may be locked either exclusively by one
transaction or by several in shared mode, but not both.

Legality of Schedules
• If xli(X) appears in a schedule, then there cannot be a
following xlj(X) or slj(X) for some j≠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).
EXAMPLE

T1 T2 Legality of schedule
sl1(A); r1(A); If sli(X) appears in a schedule, then
sl2(A); r2(A); there cannot be a following xlj(X)
for j≠i, without an intervening ui(X).
sl2(B); r2(B);
xl1(B) DENIED
u2(A); u2(B);
xl1(B); r1(B); w1(B);
u1(A); u1(B);
COMPATIBILITY MATRIX

What is it?
• Describe lock management policies involving several
lock modes.

Lock requested
S X

Lock held S Yes No

in mode
X No No
UPGRADING LOCKS
Idea
• Let T want to read and write a new value of X.
• First to take a shared lock on X.
• Later, when T was ready to write the new value, upgrade
the lock to exclusive.

T1 T2 T1 T2
sl1(A); r1(A); sl1(A); r1(A);
sl2(A); r2(A); sl2(A); r2(A);
sl2(B); r2(B); sl2(B); r2(B);
xl1(B) DENIED sl1(B); r1(B);
u2(A); u2(B); xl1(B) DENIED
xl1(B); r1(B); w1(B); u2(A); u2(B);
u1(A); u1(B); xl1(B); w1(B);
u1(A); u1(B);
UPDATE LOCKS

T1 T2
sl1(A)
sl2(A)
xl1(A) DENIED
xl2(A) DENIED

Update Lock
• An update lock uli(X) gives Ti only the privilege to read X,
not to write X.
• Only the update lock can be upgraded to a write lock
later.
• A read lock cannot be updated.
• An update lock can be granted on X even if sli(X) exists.
• Once uli(X) is given, no other modes can be taken on X.
UPDATE LOCKS

Reading
 UPDATE LOCKS

Lock requested
S X U
S Yes No Yes
Lock held in
X No No No
mode
U No No No

T1 T2 T1 T2
sl1(A) ul1(A); r1(A);
sl2(A) ul2(A) DENIED
xl1(A) DENIED xl1(A);
w1(A); u1(A);
xl2(A) DENIED
ul2(A); r2(A);
xl2(A); w2(A); u2(A);
 WORKING OF SCHEDULER
Question Assumptions
How does a scheduler use these • Transactions themselves do not request locks.
locking schemes? • Job of the scheduler to insert lock actions.
• Transactions do not release locks.
• Scheduler releases them when the transaction
manager tells it that the transaction is
READ(A); committed/ aborted.
Inserts appropriate lock
actions ahead of all DB WRITE(B);
access operations. COMMIT(T);…..
• If T aborts/ commits, it Scheduler (Part 1)
is notified by Trans
Manager.
• Releases all locks held
LOCK(A); READ(A); …..
by T. Lock
• Notifies Part 2 for
Table
waiting transactions. Scheduler (Part 2)

Determines if
Determines theT isnext
transaction
delayed as aorlock has not READ(A); WRITE(B);
transactions
been grantedthatandcan
now be given
maintains a lock list.
a waiting on X.
CONCLUSIONS

Concurrency Control
Interleaves actions (reads/writes) of various transactions
while preserving consistency

Locking-based Concurrency Control

Maintain conflict-serializability using locking.