Ullman et al.

:
Database System Principles

Textbook ch. 18: Concurrency Control

1
Concepts

Transaction: sequence of ri(x), wi(x) actions

Conflicting actions: r1(A) w2(A) w1(A)
w2(A) r1(A) w2(A)
Schedule: represents chronological order
in which actions are executed
Serial schedule: no interleaving of actions
or transactions

2
What about concurrent actions?

Ti issues System Input(X) t  X

read(X,t) issues completes
input(X)
time

T2 issues input(B) System

write(B,s) completes issues
System output(B)
issues Bs output(B)
input(B) completes
3
So net effect is either
• S=…r1(X)…w2(B)… or
• S=…w2(B)…r1(X)…

We assume that elementary actions are

atomic and follow each other.

4
What about conflicting, concurrent
actions on same object?
start r1(A) end r1(A)

start w2(A) end w2(A) time

• Assume equivalent to either r1(A) w2(A)

or w2(A)
r1(A)
•  low level synchronization mechanism
• Assumption called “atomic actions”
5
Definition

S1, S2 are conflict equivalent schedules

if S1 can be transformed into S2 by a
series of non-conflicting swaps of
adjacent actions.
A schedule is conflict serializable if it is
conflict equivalent to some serial
schedule.

6
Example:
r1(A); w1(A); r2(A); w2(A); r1(B); w1(B); r2(B); w2(B);

We claim this schedule is conflict-serializable.

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

2. r1(A); w1(A); r2(A); r1(B); w2(A); w1(B); r2(B); w2(B);
3. r1(A); w1(A); r1(B); r2(A); w2(A); w1(B); r2(B); w2(B);
4. r1(A); w1(A); r1(B); r2(A); w1(B); w2(A); r2(B); w2(B);
5. r1(A); w1(A); r1(B); w1(B); r2(A); w2(A); r2(B); w2(B);

7
• Conflict-serializability is a sufficient condition
for serializability i.e., a conflict-serializable
schedule is a serializable schedule.

• Conflict-serializability is not required for a

schedule to be serializable.

• Schedulers in commercial systems generally

use conflict-serializability when they need to
guarantee serializability.

8
Precedence graph P(S) (S is schedule)

Nodes: transactions in S (T1, T2 …)

Arcs: Ti  Tj whenever
- pi(A), qj(A) are actions in S
- pi(A) <S qj(A) (pi(A) precedes qj(A) in S)
- at least one of pi, qj is a write

9
 Exercise:
• What is P(S) for
S = w3(A) w2(C) r1(A) w1(B) r1(C) w2(A) r4(A) w4(D)

• Is S serializable?

10
 Another Exercise:
• What is P(S) for
S = w1(A) r2(A) r3(A) w4(A) ?

11
Lemma
S1, S2 conflict equivalent  P(S1)=P(S2)
Proof:
Assume P(S1)  P(S2)
  Ti: Ti  Tj in S1 and not in S2
 S1 = …pi(A)... qj(A)… pi, qj
S2 = …qj(A)…pi(A)... conflict

 S1, S2 not conflict equivalent

12
Note: P(S1)=P(S2)  S1, S2 conflict equivalent

Counter example:

S1=w1(A) r2(A) w2(B) r1(B) (cannot swap)

S2=r2(A) w1(A) r1(B) w2(B)

13
Theorem
P(S1) acyclic  S1 conflict serializable

() Assume S1 is conflict serializable

  Ss: Ss, S1 conflict equivalent
 P(Ss) = P(S1)
 P(S1) acyclic since P(Ss) is acyclic

14
Theorem
P(S1) acyclic  S1 conflict serializable
T1
() Assume P(S1) is acyclic T2 T3
Transform S1 as follows:
(1) Take T1 to be transaction with no incident arcs
T4
(2) Move all T1 actions to the front
S1 = ……. qj(A)…….p1(A)…..

(3) we now have S1 = < T1 actions ><... rest ...>

(4) repeat above steps to serialize rest!
15
How to enforce serializable schedules?

Option 1: run system, recording P(S);

at end of day, check for
P(S) cycles and declare if
execution was good

16
How to enforce serializable schedules?

Option 2: prevent P(S) cycles from

occurring
T1 T2 ….. Tn
Scheduler

DB

17
A locking protocol

Two new actions:

lock (exclusive): li (A)
unlock: ui (A)
T1 T2
lock
scheduler
table

18
Rule #1: Consistency of transactions

Ti: … li(A) … pi(A) … ui(A) ...

1. A transaction can only read or write an

element if it previously was granted a lock on
that element and hasn’t yet released the lock.
2. If a transaction locks an element, it must
later unlock that element.

19
Rule #2 Legality of schedules

S = …….. li(A) ………... ui(A) ……...

no lj(A)
Locks must have their intended meaning:
no two transactions may have locked the
same element without one having first
released the lock.

20
Exercise:
• What schedules are legal?
What transactions are consistent?
S1 = l1(A)l1(B)r1(A)w1(B)l2(B)u1(A)u1(B)
r2(B)w2(B)u2(B)l3(B)r3(B)u3(B)
S2 = l1(A)r1(A)w1(B)u1(A)u1(B)
l2(B)r2(B)w2(B)l3(B)r3(B)u3(B)
S3 = l1(A)r1(A)u1(A)l1(B)w1(B)u1(B)
l2(B)r2(B)w2(B)u2(B)l3(B)r3(B)u3(B)

21
Exercise:
• What schedules are legal?
What transactions are consistent?
S1 = l1(A)l1(B)r1(A)w1(B)l2(B)u1(A)u1(B)
r2(B)w2(B)u2(B)l3(B)r3(B)u3(B) (S1: not legal )
S2 = l1(A)r1(A)w1(B)u1(A)u1(B) (T1: not consistent)
l2(B)r2(B)w2(B)l3(B)r3(B)u3(B) (S2: not legal )
S3 = l1(A)r1(A)u1(A)l1(B)w1(B)u1(B)
l2(B)r2(B)w2(B)u2(B)l3(B)r3(B)u3(B)
(S3: legal schedule, T1,T2,T3: consistent transactions)

22
Schedule F (legal schedule of consistent transactions)
(still not equivalent to a serial schedule)
A B
T1 T2 25
25
l1(A);Read(A)
A A+100;Write(A);u1(A) 125
l2(A);Read(A)
A Ax2;Write(A);u2(A) 250
l2(B);Read(B)
B Bx2;Write(B);u2(B)
50
l1(B);Read(B)
B B+100;Write(B);u1(B)
150 23

250
Rule #3 Two phase locking (2PL)
for transactions

Ti = ……. li(A) ………... ui(A) ……...

no unlocks no locks

24
# locks
held by
Ti

Time
Growing Shrinking
Phase Phase

25
Schedule G
T1 T2
l1(A);Read(A)
A A+100;Write(A)
l1(B); u1(A)
delayed
l2(A);Read(A)
A Ax2;Write(A);l2(B)

26
Schedule G

T1 T2
l1(A);Read(A)
A A+100;Write(A)
l1(B); u1(A)
delayed
l2(A);Read(A)
A Ax2;Write(A);l2(B)
Read(B);B B+100
Write(B); u1(B)

27
Schedule G
T1 T2
l1(A);Read(A)
A A+100;Write(A)
l1(B); u1(A)
l2(A);Read(A) delayed
A Ax2;Write(A);l2(B)
Read(B);B B+100
Write(B); u1(B)
l2(B); u2(A);Read(B)
B Bx2;Write(B);u2(B);

28
Schedule G ”good” (equivalent to a serial)

A B
T1 T2 25
25
l1(A);Read(A); A A+100
Write(A); l1(B);u1(A) 125
l2(A);Read(A)
A Ax2;Write(A);
250
l2(B); delayed
Read(B);
B B+100;Write(B);u1(B)
125
l2(B);u2(A);Read(B) 29

B Bx2;Write(B);u2(B) 250
Theorem Rules #1,2,3  conflict
(consistency, legality, 2PL) serializable
schedule

30
Theorem Rules #1,2,3  conflict
(consistency, legality, 2PL) serializable
schedule

Intuitively, each two-phase-locked

transaction may be thought to execute in its
entirety at the instant it issues its first
unlock request. In a conflict-equivalent
serial schedule transactions appear in the
same order as their first unlocks.

31
Theorem Rules #1,2,3  conflict
serializable
schedule
Proof:
BASIS: If n = 1, there is nothing to do; S is already a serial
schedule.
INDUCTION: Suppose S involves n transactions
T1,T2, ... , Tn, and let Ti be the transaction with the first
unlock action in the entire schedule S, say ui (x) .
We claim it is possible to move all the read and write
actions of Ti forward to the beginning of the schedule
without passing any conflicting reads or writes.

32
Theorem Rules #1,2,3  conflict
(2PL) serializable
schedule

To help in proof:
Definition Shrink(Ti) = SH(Ti) =
first unlock action
of Ti

33
Lemma
Ti  Tj in S  SH(Ti) <S SH(Tj)
Proof of lemma:
Ti  Tj means that
S = … pi(A) … qj(A) …; p,q conflict
By rules 1,2:
S = … pi(A) … ui(A) … lj(A) ... qj(A) …

By rule 3: SH(Ti) SH(Tj)

So, SH(Ti) <S SH(Tj)
34
Theorem Rules #1,2,3  conflict
(2PL) serializable
schedule
Proof:
(1) Assume P(S) has cycle
T1  T2 …. Tn  T1
(2) By lemma: SH(T1) < SH(T2) < ... < SH(T1)
(3) Impossible, so P(S) acyclic
(4)  S is conflict serializable

35
Schedule H (T2 reversed)

T1 T2
l1(A); Read(A) l2(B);Read(B)
A A+100;Write(A) B Bx2;Write(B)
l1(B) l2(A)
delayed delayed

Deadlock !!!

36
• Assume deadlocked transactions are
rolled back
– They have no effect
– They do not appear in schedule

E.g., Schedule H =
This space intentionally
left blank!

37
Deadlocks
• Detection
– Wait-for graph
• Prevention
– Resource ordering
– Timeout
– Wait-die
– Wound-wait

38
Deadlock Detection
• Build Wait-For graph (Ti -> Tj edge if Ti waits for Tj)
• Use lock table structures
• Build incrementally or periodically
• When cycle found, rollback victim

T1 T2 T5
T7
T4 T3 T6
39
Resource Ordering (prevention)

• Order all elements A1, A2, …, An

• A transaction T can lock Ai after Aj only
if i > j

Problem : Ordered lock requests not

realistic in most cases

40
Timeout
• If transaction waits more than L sec.,
roll it back!
• Simple scheme
• Hard to select L

41
 2PL subset of Serializable
(schedules that can be implemented by 2PL locks are subset of serializable schedules)

Serializable
2PL

42
 S1: w1(x) w3(x) w2(y) w1(y)

• S1 cannot be achieved via 2PL:

The lock by T1 for y must occur after w2(y),
so the unlock by T1 for x must occur after
this point (and before w3(x)). Thus, w3(x)
cannot occur under 2PL where shown in S1
because T1 holds the x lock at that point.
• However, S1 is serializable (conflict-serializable)
(equivalent to T2, T1, T3).

43
If you need a bit more practice:
Are our schedules SC and SD 2PL schedules?

SC: w1(A) w2(A) w1(B) w2(B)

SD: w1(A) w2(A) w2(B) w1(B)

44
• Beyond this simple 2PL protocol, it is all
a matter of improving performance and
allowing more concurrency….
– Shared locks
– Multiple granularity
– Inserts, deletes and phantoms
– Other types of C.C. mechanisms

45
Shared locks
So far:
S = ...l1(A) r1(A) u1(A) … l2(A) r2(A) u2(A) …

Do not conflict

46
Shared locks
So far:
S = ...l1(A) r1(A) u1(A) … l2(A) r2(A) u2(A) …

Do not conflict

Instead:
S=... ls1(A) r1(A) ls2(A) r2(A) …. us1(A) us2(A)

47
Lock actions
l-ti(A): lock A in t mode (t is S or X)
u-ti(A): unlock t mode (t is S or X)

Shorthand:
ui(A): unlock whatever modes
Ti has locked A

48
Rule #1 Consistency of transactions
Ti =... l-S1(A) … r1(A) … u1 (A) …
Ti =... l-X1(A) … w1(A) … u1 (A) …

• A transaction may not write without

holding an exclusive lock and may not
read without holding some lock.
• All locks must be followed by an unlock
of the same element.
49
Two-phase locking of transactions:
Locking must precede unlocking.

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

50
• What about transactions that read and
write same object?

Option 1: Request exclusive lock

Ti = ...l-X1(A) … r1(A) ... w1(A) ... u(A) …

51
 • What about transactions that read and
write same object?

Option 2: Upgrade
(E.g., need to read, but don’t know if it will write…)

Ti=... l-S1(A) … r1(A) ... l-X1(A) …w1(A) ...u(A)…

Think of
- Get 2nd lock on A, or
- Drop S, get X lock

52
Rule #2 Legal scheduler

S = ....l-Si(A) … … ui(A) …

no l-Xj(A)

S = ... l-Xi(A) … … ui(A) …

no l-Xj(A)
no l-Sj(A)

53
A way to summarize Rule #2

Compatibility matrix

Comp S X
S true false
X false false

Rows: held locks

Columns: requested locks

54
A way to summarize Rule #2

Compatibility matrix

Comp S X
S true false
X false false

We can grant the lock on X (data element) in mode C (column

heading) if and only if for every row R such that there is already a
lock on X in mode R (row heading) by some other transaction,
there is a "true" in column C.
55
Rule # 3 2PL transactions

No change, take care of upgrades:

(I) If upgrade gets more locks
(e.g., S  {S, X}) then no
change!
(It is like a new lock, allowed only in the growing phase)

(II) If upgrade releases read (shared)

lock (e.g., S  X)
- can be allowed in growing phase
(We consider it as not a real release or unlock)
56
Theorem Rules 1,2,3  Conf.serializable
for S/X locks schedules

Proof: similar to X locks case

Detail:
l-ti(A), l-rj(A) (l-t and l-r can be a lock mode)
do not conflict if comp(t,r) = true

57
Lock types beyond S/X
Examples:
(1) increment lock
(2) update lock

If we introduce more lock types, it will allow more

concurrency (as it happened in case of S/X).

58