Post on 03-Jan-2016
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