Concurrency Control II

7/27/2019 Concurrency Control II

1/51

1

Concurrency Control II

More on Two Phase Locking

Time Stamp OrderingValidation Scheme


2/51

Database ImplementationConcurrency Control Yan Huang 2

Learning Objectives

Variations of two phase locking

Dealing with Deadlock and Starvation

Time Stamp Ordering Technique Validation


3/51


Schedules

Interleaved (or non-interleaved) actions from several

transactions

A schedule is good if it can be transformed into one of

the serial schedules by switching two consecutive non-

conflict actions

Weve learned 2PL to achieve serializability

It is a pessimistic scheme


4/51


Recall

2PL (two phase locking)

Locks of Ti

time

growing shrinking

Each transaction has to follow, no locking anymoreafter the first unlocking


5/51


Why 2PL serializability?

Acyclic precedence graph = serializability

Basic idea:

No cycle in precedence graph

Because

if there is a arc from Ti to Tj in precedence graph, the first unlocking

of Ti precede the first unlocking of Tj (proof details in ccI notes)

If there is circle, you will have Ti < Ti


6/51


Who will follow 2PL in practice?

Looks like it is DB application developers job.

But, they can not be trusted and too much work

Checking conformity of every transaction is costly

In practice, CC subsystems of DBMS take over the

responsibility


7/51


Variations of 2PL

Basic 2PL

Conservative 2PL

Strict 2PL Rigorous 2PL


8/51


Basic 2PL

2PL with binary locks

Covered in last class


9/51


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)


10/51


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


11/51


Well formed transactions

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

Ti =... l-X1(A) w1(A) u1 (A)


12/51


What about transactions that read and write same

object?

Option 1: Request exclusive lock

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


13/51


Option 2: Upgrade(E.g., need to read, but dont 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

What about transactions that read andwrite same object?


14/51


Compatibility matrix

Comp S X

S true false

X false false


15/51


Schedule

T1 T2l-s1(A);Read(A)

A A+100;Write(A)

l-x1(B); u1(A)

l-s2(A);Read(A)

A Ax2;Write(A); l-x2(B)

Read(B);B B+100

Write(B); u1(B)

l-x2(B); u2(A);Read(B)

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

delayed


16/51


Conservative 2PL

Lock all items it needs then transaction starts execution

If any locks can not be obtained, then do not lock anything

Difficult but deadlock free

growingshrinkinglocks

time

first action starts


17/51


Strict 2PL

T does not release any write locks until it commits or

aborts

Good for recoverability

Since reads or writes on what T writes

Deadlock free?

growing

shrinkinglocks

time

T commits or aborts

First write unlock


18/51


Rigorous 2PL

T does not release any locks until it commits or aborts

Easy to implement

Deadlock free?

growingshrinkinglocks

time

T commits or aborts


19/51


2PL

Does basic 2PL guarantee serializability?

Does conservative 2PL guarantee serializability?

Does strict 2PL guarantee serializability?

Does rigorous 2PL guarantee serializability?


20/51


Compare variations of 2PL

Deadlock

Only conservative 2PLis deadlock free

Q: give a schedule of two transactions following 2PL but

result in deadlock.


21/51


Exercises:

S1: r1(y)r1(x)w1(x)w2(x)w2(y)

S2: r1(y)r3(x)w1(x)w3(x)w2(y)w2(x)

S3: r3(y)w1(x)w3(x)r1(z)w2(y)w2(x)

Assuming binary lock right before read or write; and rigorous

2PL (release all locks right after last operation), are S1,

S2,and S3 possible?


22/51


Deadlocks Detection

Wait-for graph

Prevention

Resource ordering Timeout

Wait-die

Wound-wait


23/51


Deadlock Detection

Build Wait-For graph

Use lock table structures

Build incrementally or periodically

When cycle found, rollback victim

T1

T3

T2

T6

T5

T4T7


24/51


Resource Ordering

Order all elements A1, A2, , An

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

Problem : Ordered lock requests notrealistic in most cases


25/51


Timeout

If transaction waits more than L sec.,

roll it back!

Simple scheme

Hard to select L


26/51


Wait-die

Transactions are given a timestamp when they

arrive . ts(Ti)

Ti can only wait for Tj if ts(Ti)< ts(Tj)

...else die


27/51


T1(ts =10)

T2(ts =20)

T3(ts =25)

wait

wait

Example:

wait?

Very high level: only older ones have the privilege to wait,younger ones die if they attempt to wait for older ones


28/51


Wound-wait

Transactions are given a timestamp when they

arrive ts(Ti)

Ti wounds Tj if ts(Ti)< ts(Tj)

else Ti waits

Wound: Tj rolls back and gives lock to Ti


29/51


T1(ts =25)

T2(ts =20)

T3(ts =10)

wait

wait

Example:

wait

Very high level: younger ones wait; older ones kill (wound)younger ones who hold needed locks


30/51


Who die?

Looks like it is always the younger ones

either die automatically

or killed

What is the reason?

Will the younger ones starve?

Suggestions?


31/51


Timestamp Ordering

Key idea:

Transactions access variables according to an order decided

by their time stamps when they enter the system

No cycles are possible in the precedence graph


32/51


Timestamp

System time when transactions starts

An increasing unique number given to each stransaction

Denoted by ts(Ti)


33/51


The way it works

Two time stamps associated with each variable x

RS(x): the largest time stamp of the transactions read it

WS(x): the largest time stamp of the transactions write it

Protocol:

ri(x) is allowed if ts(Ti) >= WS(x)

wi(x) is allowed if ts(Ti) >=WS(x) and ts(Ti) >=RS(x)

Disallowed ri(x) or wi(x) will kill Ti, Ti will restart


34/51


Example

Assuming: ts(T1) = 100, ts(T2) = 200, ts(T3) = 300

T1 T2 T3

R(x);

W(y);

R (y);

W(z);

R(x);

W(z);

R(y);

W(x);

x y z

RS=-1 RS=-1 RS=-1

WS=-1 WS=-1 WS=-1


35/51


Example


T1 T2 T3

R(x);

x y z

RS=100 RS=-1 RS=-1

WS=-1 WS=-1 WS=-1


36/51


Example


T1 T2 T3

R(x);

W(y);

x y z

RS=100 RS=-1 RS=-1

WS=-1 WS=100 WS=-1


37/51


Example


T1 T2 T3

R(x);

W(y);

R (y);

x y z

RS=100 RS=200 RS=-1

WS=-1 WS=100 WS=-1


38/51


Example


T1 T2 T3

R(x);

W(y);

R (y);

W(z);

x y z

RS=100 RS=200 RS=-1

WS=-1 WS=100 WS=300


39/51


Example


T1 T2 T3

R(x);

W(y);

R (y);

W(z);

R(x);

x y z

RS=200 RS=200 RS=-1

WS=-1 WS=100 WS=300


40/51


Example


T1 T2 T3

R(x);

W(y);

R (y);

W(z);

R(x);

W(z);

x y z

RS=200 RS=200 RS=-1

WS=-1 WS=100 WS=300

T1 is rolled back


41/51


Example


T1 T2 T3

R(x);

W(y);

R (y);

W(z);

R(x);

W(z);

x y z

RS=200 RS=200 RS=-1

WS=-1 WS=100 WS=300

T1 is rolled back

What happen to RS and WS?


42/51


Net result of TO scheduling

Conflict pairs of actions are taken in the order of their

home transactions

But the basic TO does not guarantee recoverability

later


43/51


Validation

An optimistic scheme

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


44/51


Key idea

Make validation atomic If T1, T2, T3, is validation order, then resulting

schedule will be conflict equivalent to Ss = T1 T2

T3...


45/51


To implement validation, system keeps two sets:

FIN = transactions that have finished

phase 3 (and are all done)

VAL = transactions that have

successfully finished phase 2

(validation)


46/51


Example of what validation must prevent:

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

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

time

T2start

T2validated

T3validated

T3start

=


47/51


T2

finishphase 3

Example of what validation must prevent:

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

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

time

T2start

T2validated

T3validated

T3start

=

allow

T3start


48/51


Another thing validation must prevent:

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

time

T2validated

T3validated

finish

T2

BAD: w3(D) w2(D)

ll


49/51


finish

T2

Another thing validation must prevent:

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

time

T2validated

T3validated

allow

finish

T2


50/51


Validation Rule

When start validating T

Check RS(T) WS(U) is empty for U that started but did

not finish validation before T started

Check WS(T) WS(U) is empty for any U that started butdid not finish validation T start validation

start


51/51

Exercise:

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

Documents

Concurrency Control II