CE4031/CZ4031

DATABASE
SYSTEM PRINCIPLES
TRANSACTION MANAGEMENT
LOCKING-BASED CONCURRENCY CONTROL

Two-Phase Locking (2PL)

• Determine serializability order of conflicting

operations at runtime while transactions
execute.
• Pessimistic
ADDRESSING DIRTY READ

T1 T2

time
• WRITE(A)

• READ(A)

• ABORT(A)
ADDRESSING INCONSISTENT READ

T1 T2

A := 20; B := 20;
time
WRITE(A)
READ(A)

READ(B)

WRITE(B)
ADDRESSING UNREPEATABLE READ

T1 T2

time

READ(A)

WRITE(A)

READ(A)
ADDRESSING LOST UPDATE

T1 T2

READ(A) time
READ(A)
A:= A + 5

A:= A* 1.3
WRITE(A)

WRITE(A);
TIMESTAMP ORDERING (T/O)

Timestamp Ordering (T/O)

• Determine serializability order of transactions

before they execute.
• Optimistic
T/O CONCURRENCY CONTROL

Idea

Use timestamps to determine the serializability order of

transactions.

Overview

• Each transaction receives a unique timestamp TS(T).

• If TS(Ti) < TS(Tj), then the DBMS must ensure that the
execution schedule is equivalent to a serial schedule
where Ti appears before Tj.
TIMESTAMP ALLOCATION

Timestamp

• Each transaction Ti is assigned a unique fixed

timestamp that is monotonically increasing.
• Let TS(Ti) be the timestamp allocated to transaction Ti.

Implementation Strategies

• The system’s clock.

• A unique counter, incremented by the scheduler.
• Hybrid.
BASICS

Requirement

• Transactions read and write objects without locks.

• Every object X is tagged with timestamp of the last
transaction that successfully did read/ write.

RT(X) WT(X)

• Read time of X. • Write time of X.

• Highest timestamp of a • Highest timestamp of a
transaction that has transaction that has
read X. written X.
TIMESTAMP CHECK

Idea

• Check timestamps for every operation:

• If transaction tries to access an object "from the
future", it aborts and restarts.

Problems

• Read too late

• Write too late
 T/O RULES - READS

Read too late

• T tries to read DB element X but TS(T) < WT(X).

• Violates timestamp order of T with regard to the
writer of X.
• Solution: Abort T and restart it with a newer TS.

Else
U writes X
• Allow T to read X.
T reads X
• Update RT(X) to
max(RT(X), TS(T)).
• Have to make a local
copy of X to ensure
repeatable reads for T.

T start U start
 T/O RULES - WRITES

Write too late

• T want to write DB element X but TS(T) < RT(X) or

TS(T) < WT(X).
• Solution: Abort and restart T.

Else
U read X
• Allow T to write X and
T writes X
update WT(X).
• Also have to make a
local copy of X to
ensure repeatable
reads for T.

T start U start
EXAMPLE 1
Schedule Database
T1 T2 Object RT() WT()
TS(T1) = 1 TS(T2) = 2 A 0 0

r1(B); B 0 0

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

• T tries to read DB element X but TS(T) < WT(X).

• T wants to write DB element X but TS(T) < RT(X) or
TS(T) < WT(X).
EXAMPLE 1
Schedule Database
T1 T2 Object RT() WT()
TS(T1) = 1 TS(T2) = 2 A 0 0

r1(B); B 1 0

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

• T tries to read DB element X but TS(T) < WT(X).

• T wants to write DB element X but TS(T) < RT(X) or
TS(T) < WT(X).
EXAMPLE 1
Schedule Database
T1 T2 Object RT() WT()
TS(T1) = 1 TS(T2) = 2 A 0 0

r1(B); B 2 0

r2(B); Database
w2(B);
Object RT() WT()
r1(A); A 0 0
r2(A); B 2 2
w2(A);
Commit; Commit;

• T tries to read DB element X but TS(T) < WT(X).

• T wants to write DB element X but TS(T) < RT(X) or
TS(T) < WT(X).
EXAMPLE 1
Schedule Database

T1 T2 Object RT() WT()

TS(T1) = 1 TS(T2) = 2 A 0 0

r1(B); B 2 2

r2(B);
Database
w2(B);
Object RT() WT()
r1(A);
A 1 0
r2(A);
B 2 2
w2(A);
Commit; Commit;

• T tries to read DB element X but TS(T) < WT(X).

• T wants to write DB element X but TS(T) < RT(X) or
TS(T) < WT(X).
EXAMPLE 1
Schedule Database

T1 T2 Object RT() WT()

TS(T1) = 1 TS(T2) = 2 A 1 0

r1(B); B 2 2

r2(B); Database
w2(B);
Object RT() WT()
r1(A);
A 2 0
r2(A);
B 2 2
w2(A);
Commit; Commit;

• T tries to read DB element X but TS(T) < WT(X).

• T wants to write DB element X but TS(T) < RT(X) or
TS(T) < WT(X).
EXAMPLE 1
Schedule Database
No violations so
T1 T2 Object RT() WT() both transactions
TS(T1) = 1 TS(T2) = 2 A 2 0 are safe to commit.
r1(B); B 2 2
r2(B);
Database
w2(B);
Object RT() WT()
r1(A);
A 2 2
r2(A);
B 2 2
w2(A);
Commit; Commit;

• T tries to read DB element X but TS(T) < WT(X).

• T wants to write DB element X but TS(T) < RT(X) or
TS(T) < WT(X).
EXAMPLE 2
Schedule Database
T1 T2 Object RT() WT()
TS(T1) = 1 TS(T2) = 2 A 1 0

r1(A); B 0 0

w2(A);
Commit;
w1(A);
r1(A);

Commit;

• T tries to read DB element X but TS(T) < WT(X).

• T wants to write DB element X but TS(T) < RT(X) or
TS(T) < WT(X).
EXAMPLE 2
Schedule Database

T1 T2 Object RT() WT()

TS(T1) = 1 TS(T2) = 2 A 1 2

r1(A); B 0 0

w2(A);
Commit;
w1(A);
r1(A);
Commit;

• T tries to read DB element X but TS(T) < WT(X).

• T wants to write DB element X but TS(T) < RT(X) or
TS(T) < WT(X).
EXAMPLE 2
Schedule Database
T1 T2 Object RT() WT()
TS(T1) = 1 TS(T2) = 2 A 1 2

r1(A); B 0 0

w2(A);
Commit;
Violation:
w1(A);
TS(T1) < WT(A)
r1(A);
Commit;
T1 cannot overwrite
update by T2, so the
DBMS has to abort it!

• T tries to read DB element X but TS(T) < WT(X).

• T wants to write DB element X but TS(T) < RT(X) or
TS(T) < WT(X).
OPTIMIZATION – THOMAS WRITE RULE

If TS(T) < RT(X)

• Abort and restart T.

If TS(T) < WT(X)

• Thomas Write Rule: Ignore the write and allow the

transaction to continue.
• This violates timestamp order of T.

Else
• Allow T to write X and update WT(X).
 EXAMPLE 2
Schedule Database

T1 T2 Object RT() WT()

TS(T1) = 1 TS(T2) = 2 A 1 0

r1(A); B 0 0

w2(A);
Commit;
w1(A);
r1(A);
Commit;

• T tries to read DB element X but TS(T) < WT(X): Abort.

• T wants to write DB element X but TS(T) < RT(X): Abort and restart.
• T wants to write DB element X but TS(T) < WT(X): Allow to continue.
 EXAMPLE 2
Schedule Database

T1 T2 Object RT() WT()

TS(T1) = 1 TS(T2) = 2 A 1 2

r1(A); B 0 0

w2(A);
Commit;
w1(A);
r1(A);
Commit;

• T tries to read DB element X but TS(T) < WT(X): Abort.

• T wants to write DB element X but TS(T) < RT(X): Abort and restart.
• T wants to write DB element X but TS(T) < WT(X): Allow to continue.
 EXAMPLE 2
Schedule Database
We do not
T1 T2 Object RT() WT()
update WT(A)
TS(T1) = 1 TS(T2) = 2 A 1 2

r1(A); B 0 0

w2(A);
Commit;
w1(A);
r1(A);
• Ignore the write and allow T1 to continue
Commit;
• T1’s write doesn’t matter! Serial schedule:
T1 -> T2

• T tries to read DB element X but TS(T) < WT(X): Abort.

• T wants to write DB element X but TS(T) < RT(X): Abort and restart.
• T wants to write DB element X but TS(T) < WT(X): Allow to continue.
T/O TECHNIQUE

Conflict Serializable Schedule

• Generates a schedule that is conflict serializable if you

do not use the Thomas Write Rule.
• No deadlocks because no transaction ever waits.
• Possibility of starvation for long transactions if short
transactions keep causing conflicts.

Not recoverable

• Permits schedules that are not recoverable.

RECOVERABLE SCHEDULES

Recoverable Schedule

• A schedule is recoverable if transactions commit only

after all transactions whose changes they read, commit.
• T/O doesn’t check this.
• Otherwise, the DBMS cannot guarantee that
transactions read data that will be restored after
recovering from a crash.
RECOVERABLE SCHEDULES
Schedule
T1 T2
TS(T1) = 1 TS(T2) = 2
w1(A);
r2(A);
w2(B);
Commit;

T2 is allowed to read
the writes of T1
RECOVERABLE SCHEDULES
Schedule
T1 T2 This is not
TS(T1) = 1 TS(T2) = 2 recoverable as we
w1(A); cannot restart T1
r2(A);
w2(B);
Commit;

Abort;

T1 aborts after T2
has committed
 DIRTY READ REVISITED

T1 T2

WT(A) = 1
• WRITE(A)

• READ(A)

• ABORT(A)

• T tries to read DB element X but TS(T) < WT(X): Abort.

• T wants to write DB element X but TS(T) < RT(X): Abort and restart.
• T wants to write DB element X but TS(T) < WT(X): Allow to continue.
 REVISITING INCONSISTENT READ

T1 T2

RT(B) = 2
A := 20; B := 20;
TS(T1) = 1
WRITE(A)
READ(A)

READ(B)

WRITE(B)

• T tries to read DB element X but TS(T) < WT(X): Abort.

• T wants to write DB element X but TS(T) < RT(X): Abort and restart.
• T wants to write DB element X but TS(T) < WT(X): Allow to continue.
 REVISITING UNREPEATABLE READ

T1 T2
RT(A) = 2
TS(T1) = 1

READ(A)

WRITE(A)

READ(A)

• T tries to read DB element X but TS(T) < WT(X): Abort.

• T wants to write DB element X but TS(T) < RT(X): Abort and restart.
• T wants to write DB element X but TS(T) < WT(X): Allow to continue.
 REVISTING LOST UPDATE

T1 T2

RT(A) = 2
READ(A) TS(T1) = 1
READ(A)
A:= A + 5

A:= A* 1.3
WRITE(A)

WRITE(A);

• T tries to read DB element X but TS(T) < WT(X): Abort.

• T wants to write DB element X but TS(T) < RT(X): Abort and restart.
• T wants to write DB element X but TS(T) < WT(X): Allow to continue.
PERFORMANCE ISSUE

High Overhead

• High overhead from copying data to transaction’s

workspace and from updating timestamps.

Starvation

• Long running transactions can get starved.

• The likelihood that a transaction will read something
from a newer transaction increases.
TIMESTAMPS VS. LOCKING

Locks TS

• Great => many conflicts • Poor => many conflicts

• Poor => few conflicts • Great => few conflicts

Read vs. Read/ Write

• Timestamp is superior in situations where either most

transactions are read-only.
• Locking is better for read/ write environment.
CONCLUSION

ONE-PASS ALGORITHMS
Timestamp Ordering-based Concurrency Control
Maintain conflict-serializability using timestamps

Read too late

Write too late