Chapter 9

Concurrency Control
 Contents

• Concurrency Control
• Concurrency Control by Locks
• Concurrency Control by Timestamps
• Concurrency Control by Validation
 Concurrency Control
T1 T2 … Tn

DB
(consistency
constraints)

The mechanism to preserve consistency

when several transactions are executing
simultaneously on DB
Concepts
Transaction: sequence of ri(x), wi(x) actions
Schedule: a time-ordered sequence of the ac
tions taken by one or more transactions.
Serial schedule: no interleaving or mixing of
actions of different transactions
Serializable Schedule: Its effect on the data
base state is the same as that of some seri
al schedule
 Two Transactions

T1 T2
READ(A,t) READ(A,s)
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)
 Schedule A
A B
T1 T2 25 25
Read(A); A  A+100
Write(A); 125
Read(B); B  B+100;
Write(B);
125
Read(A);A  A2;
Write(A);
250
Read(B);B  B2;
Write(B);
250
250 250
Serial schedule in which T1 precedes T2
 Schedule B
A B
T1 T2 25 25
Read(A);A  A2;
Write(A); 50
Read(B);B  B2;
Write(B); 50
Read(A); A  A+100
Write(A); 150
Read(B); B  B+100;
Write(B);
150
150 150
Serial schedule in which T2 precedes T1
 Schedule C
A B
T1 T2 25 25
Read(A); A  A+100
Write(A); 125
Read(A);A  A2;
Write(A); 250
Read(B); B  B+100;
Write(B);
125
Read(B);B  B2;
Write(B);
250
250 250
A serializable, but not serial, schedule
 Schedule D
A B
T1 T2 25 25
Read(A); A  A+100
Write(A);
125
Read(A);A  A2;
Write(A);
Read(B);B  B2;
250
Write(B);
Read(B); B  B+100; 50
Write(B);
150
250 150
A nonserializable schedule
 Same as Schedule D
Schedule E but with new T2’

A B
T1 T2’ 25 25
Read(A); A  A+100
Write(A);
125
Read(A);A  A1;
Write(A);
Read(B);B  B1;
125
Write(B);
Read(B); B  B+100; 25
Write(B);
125
125 125
A schedule that is serializable only because of
the detailed behavior of the transactions.
• Consider schedules regardless of
– initial state and
– transaction semantics
• Only look at order of read and write
A Notation for Transactions and Schedules

• ri(X):Transaction Ti read database eleme

nt X
• wi(X):Transaction Ti write database elem
ent X
For example
T1:r1(A);W1(A);r1(B);W1(B)
T2: r2(A);W2(A);r2(B);W2(B)
A Schedule:
r1(A);W1(A); r2(A);W2(A) ;r1(B);W1(B) ;r2(B);W2(B)
 Conflicts
• Two actions of the same transaction, e.g ri(X);wi(X),conflict.
• Two writes of the same database element by different tra
nsactions conflict.
• A read and a write of the same database element by differ
ent transactions conflict, e.g.,ri(X);wj(X), conflict.

Conflicting actions: r1(A) r1(A) w2(A) w1(A)

w1(A) w2(A) r1(A) w2(A)

To summarize : any two actions of different transactions may

be swapped in order,unless
 They involve the same database element, and
 At least one is write.
 Conflict-Serializability
1. S1, S2 are conflict equivalent schedules if
S1 can be transformed into S2 by a series
of swaps on non-conflicting actions.
2. A schedule is conflict serializable if it is co
nflict equivalent to some serial schedule.
Example:
Sc=r1(A)w1(A)r2(A)w2(A)r1(B)w1(B)r2(B)w2(B)

Sc’=r1(A)w1(A) r1(B)w1(B)r2(A)w2(A)r2(B)w2(B)

T1 T2
Converting a conflict-serializable schedule to a
serial schedule by swaps of adjacent actions

Example :Consider the schedule

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)
However, for Sd:
Sd=r1(A)w1(A)r2(A)w2(A) r2(B)w2(B)r1(B)w1(B)
 Testing Conflict-Serializability by Pr
ecedence Graphs
Precedence graph P(S) (S is schedule)
Nodes: transactions in S
Arcs: Ti  Tj if Ti <S Tj , that is
- pi(A), qj(A) are actions in S
- pi is ahead of qj in S
- at least one of pi, qj is a write
1. If there are any cycles, S is not conflict-serializable.
2. Otherwise, S is conflict-serializable
Sc=r1(A)w1(A)r2(A)w2(A)r1(B)w1(B)r2(B)w2(B)

T1  T2 T1  T2

 no cycles  Sc is “equivalent” to a
serial schedule
(in this case T1,T2)
 For example, the following schedule S involves 3
transactions T1,T2 andT3.
S:r2(A);r1(B);w2(A);r3(A);w1(B);w3(A);r2(B);w2(B)
We can find :
T2<sT3
T1<sT2
The precedence graph for the schedule S is :

1 2 3

The conflict-equivalent serial schedule : (T1,T2,T3)

For example consider the schedule
S1:r2(A);r1(B);w2(A);r2(B);r3(A);w1(B);w3(A);W2(B)
We can find that:
T2<sT3
T1<sT2
T2<sT1

1 2 3

We conclude that S1 is not conflict-serializable.

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

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

For example:

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

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

Theorem
P(S1) acyclic  S1 conflict serializable

() Assume S1 is conflict serializable

 Ss: Ss, S1 conflict equivalent
(Ss means the serial schedule of all the transaction
s in S1 ).
 P(Ss) = P(S1)
 P(S1) acyclic since P(Ss) is acyclic
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 entry 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!
Enforcing serializability by locks
Two new actions:
lock (exclusive): li (A)
unlock: ui (A)
T1 T2
lock
scheduler
table
 Legality of Schedules
S = …….. li(A) ………... ui(A) ……...

no lj(A)

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)
Schedule F

T1 T2
l1(A);Read(A)
A A+100;Write(A);u1(A)
l2(A);Read(A)
A Ax2;Write(A);u2(A)
l2(B);Read(B)
B Bx2;Write(B);u2(B)
l1(B);Read(B)
B B+100;Write(B);u1(B)
 Schedule F
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
250 150

A legal schedule of consistent transaction, but it is not ser

ializable
 Two phase locking (2PL)
for transactions

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

no unlocks no locks

In every transaction, all lock requests precede

all unlock requests.
# locks
held by
Ti

Time
Growing Shrinking
Phase 1 Phase 2
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);ll2(B)
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);ll2(B)
Read(B);B B+100
Write(B); u1(B)
 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);ll2(B)
Read(B);B B+100
Write(B); u1(B)
l2(B); u2(A);Read(B)
B Bx2;Write(B);u2(B);

The locking scheduler delays requests that result in an illegal

schedule
 Locking Systems With Several
Lock Mode

• Shared and Exclusive Locks

• Upgrading Locks
• Update locks
• Increment locks
 Shared and Exclusive Locks
 When we want to read X, we need to get the shared or
exclusive lock on X, but we prefer the former
 When we want to write X, we need to get the exclusive l
ock on X
 Some expressions
 sli(X): transaction Ti requests a shared lock on database elemen
tX
 xli(X): transaction Ti requests an exclusive lock on database ele
ment X
 ui(X): Ti unlocks X
 Shared locks

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

Instead: Do not conflict

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

Exclusive Locks
Transactions that read and write the same objects .
Ti = ...l-X1(A) … r1(A) ... w1(A) ... u(A) …
 Three Requirements of a
Shared/Exclusive Lock System

1. Consistency of transactions
2. Two-phase locking of transactions
3. Legality of schedules
Consistency of Transactions

Ti =... l-S1(A) … r1(A) … u1 (A) …

Ti =... l-X1(A) … w1(A) … u1 (A) …
Two-phase locking of transactions

No action sli(X) or xli(X) can be preceded

by an action ui
 Legality of Schedules

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

no l-Xj(A)

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

no l-Xj(A)
no l-Sj(A)
For example :Let us examine a possible schedule
of the following two transactions,using shared and
exclusive locks:
T1:sl1(A);r1(A);xl1(B);r1(B);w1(B);u1(A);u1(B)
T2:sl2(A);r2(A);sl2(B);r2(B);u2(A);u2(B)
T1 T2
sl1(A);r1(A);
sl2(A);r2(A); Notice that the sc
hedule is conflict-
sl2(B);r2(B); serializable, the c
xl1(B) Denied onflict-equivalent
serial order is (T2,
u2(A);u2(B) T1)
xl1(B);r1(B);w1(B);
u1(A);u1(B);
The compatibility matrix for shared and
exclusive locks

Lock requested
S X

Lock held S Yes No

in mode X No No
 Upgrading Locks
• A transaction T that wants to read and writ
e a new value of X first take a shared lock
on X,and only later,when T is ready to writ
e the new value ,upgrade the lock to exclu
sive
• ui(X) releases all locks on X held by transa
ction Ti
 Upgrade
(E.g., need to read, but don’t know if will write…)

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

Think of
- Get 2nd lock on A, or
- Drop S, get X lock
Upgrading locks allows more concurrent operation
T1:sl1(A);r1(A);sl1(B);r1(B);xl1(B);w1(B);u1(A);u1(B);
T2:sl2(A);r2(A);sl2(B);r2(B);u2(A);u2(B);

T1 T2
sl1(A);r1(A);
sl2(A);r2(A);
sl2(B);r2(B);
sl1(B);r1(B);
xl1(B) Denied
u2(A);u2(B)
xl1(B);w1(B)
u1(A);u2(B)
Indiscriminate use of upgrading introduces a new source
of potentially serious source of deadlocks

T1 T2
sl1(A)
sl2(A)
Xl1(A) Denied
xl2(A)Denied
Solution
If Ti wants to read A and knows it
may later want to write A, it requests
update lock (not shared)
 Update Locks

• The update lock can be upgraded to a

write lock later; A read lock cannot be
upgraded
• We can grant an update lock on X when
there are already shared locks on X,but
once there is an update lock on X we
prevent additional locks of any kind from
being taken on X
Compatibility matrix for shared,
exclusive,and update locks

S X U

S Yes No Yes
X No No No
U No No No
The update locks can fix the deadlock problem.
T1:ul1(A);r1(A);xl1(A);w1(A);u1(A);
T2:ul2(A);r2(A);xl2(A);w2(A);u2(A);

T1 T2
ul1(A);r1(A);
ul2(A)Denied
xl1(A);w1(A);u1(A);
ul2(A);r2(A);

xl2(A);w2(A);u2(A)
 Increment Locks
• Atomic increment action: INi(A)
{Read(A); A  A+k; Write(A)}
• INi(A), INj(A) do not conflict!
INi(A) A=7 INj(A)
+2 +10
A=5 +10
A=17
+2
INj(A)
A=15
INi(A)
 A consistent transaction can only have increm
ent action on X if it holds an increment lock o
n X at the time. An increment lock does not e
nable either read or write actions
 In a legal schedule,any number of transaction
s can hold an increment lock on X at any time
 The action inci(X) conflicts with both rj(X) and
wj(X), but does not conflict with incj(X)
 Compatibility matrix for
shared,exclusive,and increment locks

S X I

S Yes No No
X No No No
I No No .Yes
T1:sl1(A);r1(A);il1(B);inc1(B);u1(A);u1(B)
T2:sl2(A);r2(A);il2(B);inc2(B);u2(A);u2(B)
T1 T2
sl1(A);r1(A);
sl2(A);r2(A);
il2(B);inc2(B);
il1(B);inc1(B);
u2(A);u2(B);
u1(A);u1(B)

S: r1(A);r2(A);inc2(B);inc1(B)
r1(A);r2(A); inc1(B);inc2(B)
r1(A); inc1(B); r2(A); inc2(B)
 Locking System
Ti

Read(A),Write(B)
Scheduler, part I
lock
table
Scheduler, part II
l(A),Read(A),l(B),Write(B)…

DB
Read(A),Write(B)
Lock table Conceptually
If null, object is unlocked
A 
Every possible object

B Lock info for B

C Lock info for C

...
But use hash table:

A
A... Lock info for A
H
...

If an object not found in hash table, it is

unlocked
 Lock info for A - example

tran mode wait? Nxt T_link

Object:A
Group mode:U
T1 S no
Waiting:yes
List: T2 U no

T3 X yes 

To other T3
records
The group mode is a summary of the most stringent
conditions that a transaction requesting a new lock on A.
 Handling Lock Requests
• If there is no lock-table entry for A, the
entry is created and the request is granted
• If the lock-table entry for A exists
– If the group mode is “update”or
“exclusive”,then the request is denied
– If the group mode is “shared”,then another
shared or update lock can be granted,and we
need to modify the group mode
 Handling Unlocks
• Delete T’s entry on the list for A
• Modify the group mode
– If the lock held by T is not the same as the group
mode,then we need not change the group mode
– Else we may have to examine the entire list to find the
new group mode
• If the value of waiting is “yes”, then we need to
grant one or more locks from the list of
requested locks
– First-come –first –served
– Priority to shared locks
– Priority to upgrading
What are the objects we lock?

Relation A Tuple A Disk

Tuple B block
Relation B Tuple C A
Disk
block ?
...

...
B

DB DB ...
DB
 Locking works in any case, but should
we choose small or large objects?

• If we lock large objects (e.g., Relations)

– Need few locks
– Low concurrency
• If we lock small objects (e.g., tuples, fields)
– Need more locks
– More concurrency
 Managing Hierarchies of Database
Elements
• A hierarchy of lockable elements, e.
g. relations  blocks  tuples
• The data that is itself organized in a tree
e.g. B-Tree
Relations
R1

Blocks B1 B2 B3

t1 t2 t3 Tuples
Stall 1 Stall 2 Stall 3 Stall 4

restroom

hall
 Warning Locks

• IS: the intention to obtain a shared lock on

a subelement
• IX: the intention to obtain a exclusive lock
on a subelement
 The rules of the warning protocol
(1) To place an ordinary S or X on any element,we
must begin at the root of the hierarchy
(2) If we are at the element that we want to lock,
we need to look no further, we request an S or X
lock on that element
(3) If the element we wish to lock is further down
the hierarchy, then we place a warning at this
node. When the lock on the current node is
granted, we proceed to the appropriate child.
We repeat step (2) or step(3) until we reach the
desired node
Compatibility matrix for shared,
exclusive,and intention locks

IS IX S X

IS Yes Yes Yes No

IX Yes Yes No No
S Yes No Yes No
X No No No No
EXAMPLE 17: Consider the relation
Movie(title,year,length,studioName)
Set a lock on the entire relation and locks on individual tuples.
T1: SELECT *
FROM Movie
WHERE title=‘King Kong’
T2: UPDATE Movie
SET year=1939
WHERE title=‘Gone With the Wind’
 T1-IS
Movies
T2-IX

King Kong King Kong Gone With the Wind

T1-S T1-S T2-X
 Handling Insertions Correctly

• The phantom problem: We can only lock

existing items; there is no easy way to
lock database elements that do not exist
but might later be inserted
Example: relation R (E#,name,…)
constraint: E# is key
suppose use tuple locking

R E# Name ….
o1 55 Smith
o2 75 Jones
T1: Insert <99,Gore,…> into R
T2: Insert <99,Bush,…> into R

T1 T2
S1(o1) S2(o1)
S1(o2) S2(o2)
Check Constraint Check Constraint

...
...

Insert o3[99,Gore,..]
Insert o4[99,Bush,..]
Solution
• Use multiple granularity tree
• Before insert of node Q,
lock parent(Q) in
X mode R1

t1
t2 t3
Back to example
T1: Insert<99,Gore> T2: Insert<99,Bush>
T1 T2
X1(R)
X2(R) delayed

Check constraint
Insert<99,Gore>
U(R)
X2(R)
Check constraint
Oops! e# = 99 already in R!
 The Motivation for Tree-Based
Locking

If using two-phase locking, concurrent use

of the B-tree is almost impossible, because
transaction can not unlock the root until it
has acquired all the locks it need.
Example
• All objects accessed
through root, T1 lock
following pointers A

B C
T1 lock T1 lock
D

E F

 Can we release A lock

if we no longer need A??
Idea: traverse like “Monkey Bars”

T1 lock
A
T1 lock
B C
T1 lock T1 lock
D

E F
Why does this work?
• Assume all Ti start at root; exclusive lock
• Ti  Tj  Ti locks root before Tj
Root

Q T i  Tj

• Actually works if we don’t always

start at root
Rules: tree protocol (exclusive locks)

(1) First lock by Ti may be on any item

(2) After that, item Q can be locked by Ti
only if parent(Q) locked by Ti
(3) Items may be unlocked at any time
(4) After Ti unlocks Q, it cannot relock Q
Three transactions following the tree protocol
T1 T2 T3 A
l1(A);r1(A)
l1(B);r1(B)
l1(C);r1(C) B C
w1(A);u1(A)
L1(D);r1(D)
W1(B);u1(B)
l2(B);r2(B) D E
l3(E);r3(E);
w1(D);u1(D)
w1(C);u1(C)
l2(E)Denied
l3(F);r3(F) F G
w3(F);u3(F)
l3(G);r3(G)
w3(E);u3(E) T1:A,B,C,D not 2PL
l2(E);r2(E)
T2:B,E 2PL
w3(G);u3(G)
w2(B);u2(B) T3:E,F,G not 2PL
• Ti<sTj: In schedule S,the transaction Ti an
d Tj lock a node in common,and Ti locks th
e node first
In the schedule S of the example, we find that
T1<sT2 (B)
T3<sT2 (E)

The equivalent serial schedule is

(T1,T3,T2) or (T3,T1,T2)
 Concurrency Control by Timestamps
• Timestamping
• Validation

Both of them are optimistic

The remedy method : rollback and restart
All locking methods are pessimistic,
The remedy method: delay, not abort
 Timestamps
• Timestamp of T (TS(T)): The time that a
transaction T notifies the scheduler that it
is beginning
• Approaches to generating timestamps
– Use the system clock
– Maintain a counter
 Timestamps
Each database element X is associated with two
timestamps and an additional bit:
– RT(X): the highest timestamp of a transaction that has
read X
– WT(X): the highest timestamp of a transaction that has
written X
– C(X): the commit bit for X, which is true if and only if
the most recent transaction to write X has already
committed.
The scheduler assumes that the timestamp
order of transactions is also the serial
order in which they must appear to execute
Two Kinds of Unrealizable Behaviors

• Read too late

• Write too late

U writes X T reads X U reads X T writes X

T start U start T start U start

Read too late Write too late
Problems With Dirty Data
U writes X T reads X

U start T start U abort

Thomas write rule: writes can be skipped when
a write with a later write-time is already in place.

U writes X T writes X

T start U start T commits

U aborts

A potential problem with thomas write rule

Solution: when write(X), set C(X) to be false and make
a copy of the old value of X and its previous WT(X).
 The Rules for Timestamp-Based
Scheduling
• For read request, see whether it is too
late.
• For write request, see whether it is too late.
• For commit request, set commit bit.
• For abort or roll back request, resume the
other transaction.
• Suppose the scheduler receives a request r T(X)
– If TS(T)≥WT(X), the read is physically realizable
• If c(X) is true,grant the request.If TS(T)>RT(X), set RT(X):=T
S(T); otherwise so not change RT(X)
• If c(X) is false,delay T until c(X) becomes true or the transacti
on that wrote X aborts
– If TS(T)<WT(X), read too late. Rollback T;
• Suppose the scheduler receives a request wT
(X)
– If TS(T) ≥RT(X) and TS(T) ≥WT(X), the write is phy
sically realizable and must be performed.
• Write the new value for X
• Set WT(X):=TS(T),and
• Set c(X):=false
– If TS(T) ≥RT(X) ,but TS(T) <WT(X), follow Thomas
write rule.
– If TS(T) <RT(X),then write too late
• Suppose the scheduler receives a request to
commit T. (1) Set c(X):=true for all database
elements X written by T. (2) Resume any
transactions that are waiting for T to be
committed
• Suppose the scheduler request to abort T or
decides to rollback T as in 1b or 2c.Then any
transaction that was waiting on an element X
that T wrote must repeat its attempt to read or
write,and see whether the action is now legal
after the aborted transaction’s writes are
cancelled
Three transactions executing under a timestamp-based scheduler

T1 T2 T3 A B C
200 150 175 RT=0 RT=0 RT=0
WT=0 WT=0 WT=0
r1(B) RT=200
r2(A) RT=150
r3(C) RT=175
w1(B) WT=200
w1(A) WT=200
w2(C)
Abort
w3(A)
 Multiversion Timestamps

Maintain old versions of database elements in

addition to the current version.
T3 must abort because it cannot access an old value of A

T1 T2 T3 T4 A
150 200 175 225 RT=0
WT=0
r1(A) RT=150
w1(A) WT=150
r2(A) RT=200
w2(A) WT=200
r3(A)
Abort
r4(A) RT=225
Execution of transactions using multiversion concurrency control

T1 T2 T3 T4 A0 A150 A200
150 200 175 255
r1(A) read
W1(A) create
r2(A) read
w2(A) create
r3(A) read
r4(A) read
 Timestamps and Locking
• In low-conflict situations, timestamp
performs better
• In high-conflict situations, locking performs
better.
 Concurrency Control by
Validation

• Allow transactions to access data without l

ocks
• Check the serializability at the appropriate
time.
Validation
Transactions have 3 phases:
(1) Read
– all DB values read
– writes to temporary storage
– no locking
(2) Validate
– check if schedule so far is serializable
(3) Write
– If validate ok, write to DB
Key idea
• Make validation atomic
• If T1, T2, T3, … is validation order, then
resulting schedule will be conflict
equivalent to Ss = T1 T2 T3...
To implement validation, system keeps three sets:
• START=transactions that have started, but not
yet completed
• VAL = transactions that have successfully
finished phase 2 (validation)
• FIN = transactions that have finished phase
3 (and are all done)
 The Validation Rules

1 T reads X U writes X

T start
U start T validating
U validated

T cannot validate if an earlier transaction is now writing something that T

should have read
Example of what validation must prevent:

RS(T2)={B}  RS(T3)={A,B}= 
WS(T2)={B,D} WS(T3)={C}

T2 T3 T2 T3
start validated validated
start

time

RS(T): the set of database elements T reads

WS(T): the set of database elements T writes
 allow
Example of what validation must prevent:

RS(T2)={B}  RS(T3)={A,B}= 
WS(T2)={B,D} WS(T3)={C}

T2 T3 T2 T3
start validated validated
start

T2 T3
time
finish start
phase 3
 2 T writes X

U writes X

U validated T validating

U finish
T cannot validate if it could then write something
ahead of an earlier transaction
Another thing validation must prevent:
RS(T2)={A} RS(T3)={A,B}
WS(T2)={D,E} WS(T3)={C,D}

T2 T3
validated validated
finish
T2 time
BAD: w3(D) w2(D)
 allow
Another thing validation must prevent:
RS(T2)={A} RS(T3)={A,B}
WS(T2)={D,E} WS(T3)={C,D}

T2 T3
validated validated
finish finish
T2 T2 time
 For validating a transaction T
• Compare RS(T) with WS(U) and check
that RS(T)WS(U)= for any U that did
not finish before T started,i.e.,if
FIN(U)>START(T)
• Compare WS(T) with WS(U) and check
that WS(T)  WS(U)= for any U that did
not finish before T VALIDATED,i.e.,if
FIN(U)>VAL(T)
 start
Example: validate
finish

U: RS(U)={B} W: RS(W)={A,D}
WS(U)={D} WS(W)={A,C}

T: RS(T)={A,B} V: RS(V)={B}
WS(T)={A,C} WS(V)={D,E}
Validation of U : it validates successfully
Validation of T: ,
RS(T) WS(U)={A,B} {D}= 
WS(T) WS(U)={A,C} {D}= 
Validation of V
RS(V) WS(T)={B} {A,C}= 
WS(V) WS(T)={D,E} {A,C}= 
RS(V) WS(U)={B} {D}= 
Validation of W
RS(W) WS(T)={A,D} {A,C}= {A}
RS(W) WS(V)={A,D} {D,E}= {D}
WS(W) WS(V)={A,C} {D,E}= 
W is rolled back
 Comparison of Three Concurrency-
Control Mechanisms
• Storage utilization
– Locks:space in the lock table is proportional to the
number of database elements locked
– Timestamps: Store read- and write-times in a table
analogous to a lock table
– Validation:Space is used for timestamps and
read/write sets for each currently active transaction
• The ability to complete without delay
– Locking delays but avoids rollbacks, timestamps and
validation do not delay, but cause them to rollback
Summary
Have studied C.C. mechanisms used in
practice
- 2 PL
- Multiple granularity
- Tree (index) protocols
- Timestamp
- Validation