Chapter 9

Concurrency Control

Contents

• Concurrency Control

• Concurrency Control by Locks

• Concurrency Control by Timestamps

• Concurrency Control by Validation

Concurrency Control

The mechanism to preserve consistency when several transactions are executing simultaneously on DB

T1 T2 … Tn

DB(consistencyconstraints)

Concepts

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

Schedule: a time-ordered sequence of the actions taken by one or more transactions.

Serial schedule: no interleaving or mixing of actions of different transactions

Serializable Schedule: Its effect on the database state is the same as that of some serial 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

T1 T2

Read(A); A A+100

Write(A);

Read(B); B B+100;

Write(B);

Read(A);A A2;

Write(A);

Read(B);B B2;

Write(B);

A B25 25

125

125

250

250250 250

Serial schedule in which T1 precedes T2

Schedule B

T1 T2

Read(A);A A2;

Write(A);

Read(B);B B2;

Write(B);

Read(A); A A+100

Write(A);

Read(B); B B+100;

Write(B);

A B25 25

50

50

150

150150 150

Serial schedule in which T2 precedes T1

Schedule C

T1 T2

Read(A); A A+100

Write(A);

Read(A);A A2;

Write(A);

Read(B); B B+100;

Write(B);

Read(B);B B2;

Write(B);

A B25 25

125

250

125

250250 250

A serializable, but not serial, schedule

Schedule D

T1 T2

Read(A); A A+100

Write(A);

Read(A);A A2;

Write(A);

Read(B);B B2;

Write(B);

Read(B); B B+100;

Write(B);

A B25 25

125

250

50

150250 150

A nonserializable schedule

Schedule E

T1 T2’

Read(A); A A+100

Write(A);

Read(A);A A1;

Write(A);

Read(B);B B1;

Write(B);

Read(B); B B+100;

Write(B);

A B25 25

125

125

25

125125 125

Same as Schedule Dbut with new T2’

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 element X

• wi(X):Transaction Ti write database element 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 conflict equivalent to some serial schedule.

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

T1 T2

Example:

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

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)

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

However, for Sd:

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

Testing Conflict-Serializability by Precedence 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 transactions in S1 ).

P(Ss) = P(S1)

P(S1) acyclic since P(Ss) is acyclic

() Assume P(S1) is acyclic

Transform S1 as follows:(1) Take T1 to be transaction with no entry arcs

(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!

T1

T2 T3

T4

Theorem

P(S1) acyclic S1 conflict serializable

Two new actions:

lock (exclusive): li (A)

unlock: ui (A)

scheduler

T1 T2

locktable

Enforcing serializability by locks

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

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 B

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

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)

l2(A);Read(A)

A Ax2;Write(A);ll22(B)(B)

delayed

Schedule G

T1 T2

l1(A);Read(A)

A A+100;Write(A)

l1(B); u1(A)

l2(A);Read(A)

A Ax2;Write(A);ll22(B)(B)

Read(B);B B+100

Write(B); u1(B)

delayed

Schedule G

T1 T2

l1(A);Read(A)

A A+100;Write(A)

l1(B); u1(A)

l2(A);Read(A)

A Ax2;Write(A);ll22(B)(B)

Read(B);B B+100

Write(B); u1(B)

l2(B); u2(A);Read(B)

B Bx2;Write(B);u2(B);

delayed

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 lock on X

Some expressions sli(X): transaction Ti requests a shared lock on database elemen

t X 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) …

Do not conflictInstead:

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);

sl2(B);r2(B);

xl1(B) Denied

u2(A);u2(B)

xl1(B);r1(B);w1(B);

u1(A);u1(B);

Notice that the schedule is conflict-serializable, the conflict-equivalent serial order is (T2,T1)

The compatibility matrix for shared and exclusive locks

Lock requested

S X

Lock held in mode

S

X

Yes No

No No

Upgrading Locks

• A transaction T that wants to read and write a new value of X first take a shared lock on X,and only later,when T is ready to write the new value ,upgrade the lock to exclusive

• ui(X) releases all locks on X held by transaction 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

X

U

Yes No Yes

No No No

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!

A=7

A=5 A=17

A=15

INi(A)+2

INj(A)+10

+10

INj(A)+2

INi(A)

A consistent transaction can only have increment action on X if it holds an increment lock on X at the time. An increment lock does not enable either read or write actions

In a legal schedule,any number of transactions 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

X

I

Yes No No

No No No

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)

Ti

Read(A),Write(B)

l(A),Read(A),l(B),Write(B)…

Read(A),Write(B)

Scheduler, part I

Scheduler, part II

DB

locktable

Locking System

Lock table Conceptually

A

BC

...

Lock info for B

Lock info for C

If null, object is unlocked

Every

poss

ible

obje

ct

But use hash table:

A

If an object not found in hash table, it is unlocked

Lock info for AA

......

H

Lock info for A - example

tran mode wait? Nxt T_link

Object:AGroup mode:UWaiting:yesList:

T1 S no

T2 U no

T3 XX 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

Relation B

...

Tuple ATuple BTuple C

...

Disk block

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

R1

B1 B2 B3

t1 t2 t3

Relations

Blocks

Tuples

hall

Stall 1 Stall 2 Stall 3 Stall 4

restroom

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

Yes Yes Yes No

Yes Yes No No

Yes No Yes No

No No No No

IS IX S X

IS

IX

S

X

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

T2-IXMovies

King Kong

T1-S

King Kong

T1-S

Gone With the Wind

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 RT2: 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

t1t2 t3

Back to exampleT1: Insert<99,Gore> T2: Insert<99,Bush>

T1 T2

X1(R)

Check constraintInsert<99,Gore>U(R)

X2(R)Check constraintOops! e# = 99 already in R!

XX22(R(R))

delayed

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

A

B C

D

E F

• All objects accessed through root, following pointers

T1 lock

T1 lockT1 lock

Can we release A lock if we no longer need A??

Idea: traverse like “Monkey Bars”

A

B C

D

E F

T1 lock

T1 lockT1 lock

T1 lock

Why does this work?

• Assume all Ti start at root; exclusive lock• Ti Tj Ti locks root before Tj

• Actually works if we don’t always start at root

Root

Q Ti Tj

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 protocolT1 T2 T3

l1(A);r1(A)

l1(B);r1(B)

l1(C);r1(C)

w1(A);u1(A)

L1(D);r1(D)

W1(B);u1(B)

l2(B);r2(B)

l3(E);r3(E);

w1(D);u1(D)

w1(C);u1(C)

l2(E)Denied

l3(F);r3(F)

w3(F);u3(F)

l3(G);r3(G)

w3(E);u3(E)

l2(E);r2(E)

w3(G);u3(G)

w2(B);u2(B)

w2(E);u2(E)

A

B C

D E

F G

T1:A,B,C,D not 2PL

T2:B,E 2PL

T3:E,F,G not 2PL

• Ti<sTj: In schedule S,the transaction Ti and Tj lock a node in common,and Ti locks the node first

In the schedule S of the example, we find that

T1<sT2 (B)

T3<sT2 (E)

1

3

2

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 restartAll 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

T start U start

U writes X T reads X

T start U start

U reads X T writes X

Read too late Write too late

Problems With Dirty DataU writes X T reads X

U start T start U abort

T start U start

U writes X T writes X

T commitsU aborts

A potential problem with thomas write rule

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

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 rT(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):=TS(T); otherwise so not change RT(X)

• If c(X) is false,delay T until c(X) becomes true or the transaction 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

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)

Three transactions executing under a timestamp-based scheduler

Multiversion Timestamps

Maintain old versions of database elements in addition to the current version.

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

T3 must abort because it cannot access an old value of A

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 locks

• 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

T reads X U writes X

U startT start

U validatedT validating

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

1

Example of what validation must prevent:

RS(T2)={B} RS(T3)={A,B}

WS(T2)={B,D} WS(T3)={C}

time

T2

start

T2

validated

T3

validatedT3

start

=

RS(T): the set of database elements T readsWS(T): the set of database elements T writes

T2

finishphase 3

Example of what validation must prevent:

RS(T2)={B} RS(T3)={A,B}

WS(T2)={B,D} WS(T3)={C}

time

T2

start

T2

validated

T3

validatedT3

start

=

allow

T3

start

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

2

Another thing validation must prevent:

RS(T2)={A} RS(T3)={A,B}

WS(T2)={D,E} WS(T3)={C,D}

time

T2

validatedT3

validated

finish

T2BAD: w3(D) w2(D)

finish

T2

Another thing validation must prevent:

RS(T2)={A} RS(T3)={A,B}

WS(T2)={D,E} WS(T3)={C,D}

time

T2

validatedT3

validated

allow

finish

T2

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)

Example:

T: RS(T)={A,B} WS(T)={A,C}

V: RS(V)={B} WS(V)={D,E}

U: RS(U)={B} WS(U)={D}

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

startvalidatefinish

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