Con Currency

Principles of Database Management Systems
8: Concurrency Control
Pekka Kilpelinen
(after Stanford CS245 slide originals by Hector Garcia-Molina, Jeff Ullman and Jennifer Widom)
DBMS 2001 Notes 8: Concurrency 1
Chapter 9
T1 T2
Concurrency Control
Tn
How to prevent harmful interference btw transactions?
=> scheduling techniques based on - locks - timestamps and validation
Notes 8: Concurrency 2
DB (consistency constraints)
DBMS 2001
Example:
T1: Read(A) A n A+100 Write(A) Read(B) B n B+100 Write(B)
Constraint: A=B T2: Read(A) A n Av2 Write(A) Read(B) B n Bv2 Write(B)
DBMS 2001
Notes 8: Concurrency
Correctness depends on scheduling of transactions A schedule - Chronological (possibly interleaving) order in which actions of transactions are executed - A correct schedule is equivalent to executing transactions one-at-a-time in some order
Schedule A
T1 Read(A); A n A+100; Write(A); Read(B); B n B+100; Write(B); T2 A 25 125 125 Read(A);A n Av2; Write(A); Read(B);B n Bv2; Write(B); 250 250 250
5
B 25
OK
DBMS 2001 Notes 8: Concurrency
250
Schedule B
T1 T2 Read(A);A n Av2; Write(A); Read(B);B n Bv2; Write(B); Read(A); A n A+100; Write(A); Read(B); B n B+100; Write(B); 150 150 150
6
A 25 50
B 25
50
OK
150
Schedule C
T1 Read(A); A n A+100 Write(A); T2 A 25 125 Read(A);A n Av2; Write(A); Read(B); B n B+100; Write(B); Read(B);B n Bv2; Write(B); 250 125 250 250
7
B 25
OK
250
Schedule D
T1 Read(A); A n A+100; Write(A); T2 A 25 125 Read(A);A n Av2; Write(A); Read(B);B n Bv2; Write(B); Read(B); B n B+100; Write(B); Constraint violation!
B 25
250 50 150 150

8
250
Schedule E
Same as Schedule D but with new T2
T1 Read(A); A n A+100; Write(A);
T2
A 25 125
B 25
Read(A);A n Av1; Write(A); Read(B);B n Bv1; Write(B); Read(B); B n B+100; Write(B);
125 25 125 125

9
OK
125
Want schedules that are good , regardless of initial state ( " good in any DB state) and transaction semantics
Only look at order of READs and WRITEs

Note: transactions see values in buffers, not on disk => this time ignore INPUT/OUTPUTs Example: Sa (Schedule a) = r1(A)w1(A)r1(B)w1(B) r2(A)w2(A) r2(B)w2(B) T1
T2
10
A schedule is serial, if actions of transactions are not interleaved

e.g., (T1, T2) or (T2, T1) A serial schedule obviously maintains consistency (assuming correctness of individual transactions)
Could we reorder a schedule into an equivalent serial schedule?

Actions conflict, if swapping them may change the meaning of a schedule: any two actions of a single transaction two actions on a common DB element A, one of which is WRITE(A)
Example: (of swapping non-conflicting actions) Sc=r1(A)w1(A)r2(A)w2(A)r1(B)w1(B)r2(B)w2(B)

r1(B) w2(A) r1(B)r2(A) w1(B)w2(A)
Sc =r1(A)w1(A) r1(B)w1(B)r2(A)w2(A)r2(B)w2(B) T1
T2
12
However, for Sd: Sd=r1(A)w1(A)r2(A)w2(A)r2(B)w2(B)r1(B)w1(B)
Sd cannot be rearranged into a serial schedule

Sd is not equivalent to any serial schedule Sd is bad
DBMS 2001
13
Concepts
Transaction: sequence of ri(x), wi(x) actions Conflicting actions: rh(A) wh(A) wh(A) wk(A) rk(A) wk(A)
If schedule S contains conflicting actions , ph(A), , qk(A), ... [i.e., one of p, q is w], transaction Th must precede Tk in a corresponding serial schedule. Denote this by Th " Tk
Returning to Sc
Sc=r1(A)w1(A)r2(A)w2(A)r1(B)w1(B)r2(B)w2(B) T1 p T2 T1 p T2
No cycles Sc is equivalent to a serial schedule (in this case T1,T2)

Definition
S1, S2 are conflict equivalent schedules if S1 can be transformed into S2 by a series of swaps on non-conflicting actions.
(=> effect of both S1 and S2 on the DB is the same)
DBMS 2001
16
Definition
A schedule is conflict serializable if it is conflict equivalent to some serial schedule.
NB: Conflict serializability is a sufficient (but not a necessary) condition for serializability (equivalence to some serial schedule) Easier to enforce than serializability, therefore generally assured by commercial systems
Precedence graph P(S) (S
is schedule)
Nodes: transactions T1, T2, ... in S Arcs: Ti p Tj for i { j whenever - pi(A), qj(A) are conflicting actions in S,
(same element A, at least one of actions is a write)
- action pi(A) precedes qj(A) in S
DBMS 2001
18
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?
Lemma Let S1, S2 be schedules for the

same set of transactions S1, S2 conflict equivalent P(S1)=P(S2) Proof: Assume P(S1) { P(S2) Ti: Ti p Tj in P(S1) and not in P(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 Counter example: S1= w1(A) r2(A) w2(B) r1(B) S2= r2(A) w1(A) r1(B) w2(B)
DBMS 2001
21
Theorem I
P(S1) acyclic S1 conflict serializable () Assume S1 is conflict serializable serial Ss: Ss, S1 conflict equivalent P(Ss) = P(S1) [ Lemma] P(S1) acyclic since P(Ss) is acyclic
DBMS 2001
22
Theorem (cont.)
P(S1) acyclic S1 conflict serializable () Assume P(S1) is acyclic T1 Transform S1 as follows: T2 T4 T3
(1) Take T1 to be transaction with no incoming arcs (2) Move all T1 actions to the front S1 =
qj(X)
p1(A)
(3) we now have S1 = < T1 actions ><... rest ...> (4) repeat above steps to serialize rest!
How to enforce serializable schedules?

Option 1: (Optimistic strategy) Run system, recording P(S); At end of day, check P(S) for cycles, and declare if execution was good
DBMS 2001
24
How to enforce serializable schedules?

Option 2: (Pessimistic strategy) Prevent occurrence of cycles in P(S) T1 T2 .. Tn Scheduler DB
A locking protocol
Two new actions: lock (exclusive): unlock: Tj
lj(A) uj(A) Ti lock table
scheduler
DBMS 2001
26
Rule #1: Well-formed transactions

Ti: li(A) pi(A) ui(A) ...
Lock elements (A) before accessing them

(pi is a read or a write)
Eventually, release the locks
(ui(A))
DBMS 2001
27
Rule #2
S=
Legal scheduler
... ui(A) ...
.. li(A)
no lj(A) for i { j
At most one transaction Ti can hold a lock on any element A
DBMS 2001
28
Exercise:
What schedules are legal? What transactions are well-formed?
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)
Schedule F (with simple locking)

T1 l1(A);Read(A) A:=A+100;Write(A);u1(A) T2
A B
25 25 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 Constraint violation! 250 150
30
DBMS 2001
Simple-minded locking not sufficient to ensure serializability (i.e., correctness)! " More advanced protocol known as "two phase locking"
DBMS 2001
31
Rule #3 Two phase locking (2PL)

for transactions
Ti =
. li(A)
... ui(A)
no locks
...
no unlocks
All lock requests of a transaction have to precede its unlock requests
DBMS 2001
32
# locks held by Ti
Time Growing Phase Shrinking Phase
DBMS 2001
33
Schedule G (with 2PL)

T1 l1(A); Read(A) A:=A+100;Write(A) l1(B); u1(A); T2
l1(A); Read(A) l A:=Ax2;Write(A);l2(B) Read(B);B:=B+100 Write(B); u1(B);
delayed
l2(B); u2(A);Read(B) B:=Bx2;Write(B); u2(B);

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

delayed
Neither proceeds: a deadlock

System must rollback (= abort & restart) at least one of T1, T2
Next step:
Show that Rules #1,2,3 conflict (2PL) serializable schedule
DBMS 2001
36
To help in proof: Definition Shrink(Ti) = SH(Ti) = first unlock action of Ti

# locks held by Ti T2 T1 Time SH(T2)
DBMS 2001
SH(T1)
37
Lemma Let S be a 2PL schedule. Ti p Tj in P(S) SH(Ti) <S SH(Tj) Proof of lemma: Ti p Tj means that qj (A) ; p,q conflict S = pi(A) By rules 1,2: S = pi(A) ui(A) lj(A) ... qj(A) By rule 3:
DBMS 2001
SH(Ti)
SH(Tj)
38
So, SH(Ti) <S SH(Tj)

Theorem II Rules #1,2,3 (that is, 2PL)
conflict
serializable schedule Proof: Let S be a 2PL schedule. Assume P(S) has cycle T1 p T2 p . Tn p T1 By Lemma: SH(T1) < SH(T2) < ... < SH(T1) Impossible, so P(S) acyclic S is conflict serializable (by Th. I)
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
Timestamping Validation
DBMS 2001
40
Shared locks
So far only exclusive locks: S = ...l1(A) r1(A) u1(A) l2(A) r2(A) u2(A)
Do not conflict " locking unnecessary
Instead, use shared locks (S) for reading: S=... ls1(A) r1(A) ls2(A) r2(A) . u1(A)u2(A)
DBMS 2001
41
Write actions conflict " use exclusive (X) locks for writing Lock actions: l-mk(A): lock A in mode m (S or X) for Tk uk(A): release (whatever) lock(s) held by transaction Tk on element A
DBMS 2001
42
Rule #1
Well-formed transactions
r1(A) w1(A) u1(A) u1(A)
Ti =... l-S1(A) Ti =... l-X1(A) Request
an S-lock for reading an X-lock for writing
Release the locks eventually
DBMS 2001
43
What about transactions that first read and later write the same element? Option 1: Request exclusive lock Ti = ...l-X1(A) r1(A) ... w1(A) ... u1(A) Option 2: Upgrade
(E.g., need to read, but don t know if will write )
Ti=... l-S1(A)
r1(A) ... l-X1(A)
w1(A) ...u(A)
Think as getting 2nd lock on A
DBMS 2001
44
Rule #2 Legal scheduler

S = ....l-Si(A) ui(A)
no l-Xj(A) for j { i S = ... l-Xi(A) ui(A)
no l-Xj(A) for j { i no l-Sj(A) for j { i

A way to summarize Rule #2

Compatibility matrix: S true false
Lock requested by some Tj
Locks already held by some Ti
S X
X false false
True <=> OK to give a new lock of requested kind
DBMS 2001
46
Rule # 3
(2PL)
Only change to previous: Lock upgrades S(A) p {S(A), X(A)} or S(A) p X(A) are allowed only in the growing phase
DBMS 2001
47
Theorem Rules 1,2,3 Conf.serializable for S/X locks schedules Proof: Similar to the X locks case
Lock types beyond S/X

Examples: (1) update lock (2) increment lock (see the textbook)
Update locks
A common deadlock problem with upgrades: T1 T2 l-S1(A) l-S2(A) l-X1(A) l-X2(A) --- Deadlock --DBMS 2001 Notes 8: Concurrency 49
Solution
If Ti wants to read A and knows it may later want to write A, it requests an update lock (not shared)
DBMS 2001
50
New request Comp

Lock already held in
S X U
S T F F
X F F F
U T F F
As before
DBMS 2001
51
Note: object A may be locked in different modes at the same time... S1=...l-S1(A) l-S2(A) l-U3(A) To grant a lock in mode m, mode m must be compatible with all currently held locks on object
DBMS 2001
52
How does locking work in practice?

Every system is different
(E.g., may not even provide CONFLICT-SERIALIZABLE schedules)
Here is one (simplified) way ...
DBMS 2001
53
Sample Locking System:

(1) Don t trust transactions to request/release locks (2) Do not release locks until transaction commits/aborts:
# locks
time
DBMS 2001
54
Ti Read(A),Write(B) Scheduler, part I lock table

Insert appropriate lock requests
l(A),Read(A), l(B),Write(B) Scheduler, part II

Execute or delay, based on existing locks
Read(A),Write(B) DB
DBMS 2001
55
Lock table
Every possible object
Conceptually
If null, object is unlocked 0 Lock info for B Lock info for C 0
A B C
...
Notes 8: Concurrency 56
DBMS 2001
But use hash table:

... A
h
A ...
Lock info for A
If object not found in hash table, it is unlocked

Lock info for A - example

tran mode wait? Nxt T_link
Element: A Group mode: U Waiting: yes List:
T1 T2 T3
S U X
no no yes 0
To other lock table entries of transaction T3
DBMS 2001
58
What are the objects we lock?

Relation A Relation B Tuple A Tuple B Tuple C Disk block A Disk block B
DB
DBMS 2001
...
DB
...
DB
59
...
Locking works in any case, but should we choose small or large objects? If we lock large objects (e.g., Relations)
Need few locks Get low concurrency
If we lock small objects (e.g., tuples,fields)

Need more locks (=> overhead higher) Get more concurrency
DBMS 2001
60
We can have it both ways!!

Ask any janitor to give you the solution...
Stall 1 Stall 2 Stall 3 Stall 4
restroom
hall
DBMS 2001
61
Warning Protocol
Hierarchically nesting elements (e.g. relation/block/tuple) can be locked with intention locks IS and IX Idea
start locking at the root (relation) level to place an S or X lock on a subelement, first place a corresponding intention lock IS or IX the element itself
Warns others: "I'll be reading/writing some subelement of this element"
Example (T1 reads t2, T2 reads R1)

T1(IS) , T2(S)
R1 t1 t2
T1(S)
t3
t4
DBMS 2001
63
Example (T1 reads t2, T2 writes to t4)

T1(IS) , T2(IX)
R1 t1 t2
T1(S)
t3
t4
T2(X)
DBMS 2001
64
Compatibility of multiple granularity locks Comp Requestor IS IX S X T T F F T F T F F F F F

As before
IS T Holder IX T S T X F
DBMS 2001
65
Parent locked in IS IX S X
Child can be locked in

IS, S IS, S, IX, X [S, IS; not necessary] none
P C
DBMS 2001
66
Rules
(1) Follow multiple granularity comp function (2) Lock root of tree first, any mode (3) Node Q can be locked by Ti in S or IS only if parent(Q) can be locked by Ti in IX or IS (4) Node Q can be locked by Ti in X,IX only if parent(Q) locked by Ti in IX (5) Ti is two-phase (6) Ti can unlock node Q only if none of Q s children are locked by Ti
Exercise:
Can T2 write element f2.2? What locks will T2 get?
T1(IX)
R1 t3 f3.1 f3.2
68
t1
T1(IX) t2 T1(X) f2.1
DBMS 2001
t4
f2.2
Exercise:
T1(IX)
R1 t3 f3.1 f3.2
69
t1
T1(X)
t2 f2.2
t4
f2.1
DBMS 2001
Exercise:
T1(IS)
R1 t3 f3.1 f3.2
70
t1
T1(S)
t2 f2.2
t4
f2.1
DBMS 2001
Exercise:
Can T2 read element f2.2? What locks will T2 get?
T1(S,IX)
R1 t3 f3.1 f3.2
71
t1
T1(IX) t2 T1(X) f2.1
DBMS 2001
t4
f2.2
Exercise:
T1(S,IX)
R1 t3 f3.1 f3.2
72
t1
T1(IX) t2 T1(X) f2.1
DBMS 2001
t4
f2.2
Deletions similar to writes:

Get an exclusive lock on A before deleting A Insertions more problematic:
possible to lock only existing elements
Phantom tuples:
tuples that should have been locked, but did not exist when the locks were taken
Phantom tuples
Example: relation R (E#,name, ) constraint: E# is key use tuple locking R t1 t2
DBMS 2001
E# Name 55 Bush 75 Clinton
FInit G W
74
T1: Insert <99,Gore,A, > into R T2: Insert <99,Bush,G, > into R
T1 l-S1(t1) l- S1(t2) Check Constraint Insert [99,Gore,A,..] Insert [99,Bush,G,..]
T2
l-S2(t1) l-S2(t2) Check Constraint ...
...
Solution
Use multiple granularity tree Before insert of node Q, lock parent(Q) in R1 X mode t1 t2 t3
DBMS 2001
76
Back to example
T1: Insert<99,Gore,A> T1 l-X1(R) T2: Insert<99,Bush,G> T2 L-X2(R) Check constraint Insert<99,Gore,A> u1(R) l-X2(R) Check constraint Oops! e# = 99 already in R!
delayed
DBMS 2001
77
Validation
Lock-based concurrency control is pessimistic: non-serializable schedules are prevented in advance Another, optimistic strategy: allow transaction Ti access data without locks, but record elements read or written by Ti (in read and write sets RS(Ti) and WS(Ti)) at the end validate that the actions correspond to some serial schedule
Validation
Transactions have 3 phases: (1) Read
all accessed DB elements read writes to temporary storage (no locking)
(2) Validate
check if schedule so far is serializable; if yes, then ...
(3) Write
write updated elements to DB
Key idea
Make validation an atomic operation
i.e., validate a single transaction at a time
If T1, T2, T3, is validation order, then resulting schedule will be conflict equivalent to Ss = T1 T2 T3...
DBMS 2001
80
To implement validation, system maintains two sets of transactions: FIN = transactions that have finished phase 3 (writing, and are completed) VAL = transactions that have successfully finished phase 2 (validation), but not yet completed
DBMS 2001
81
Example of what validation must prevent: RS(T2)={B} RS(T3)={A,B} WS(T2)={B,D} { J WS(T3)={C}

T2
start
T3
start
T2
validated
T3
validating
T2 may have written B after T3 read B, contradicting the assumed serial order (T2, T3) " T3 is rolled back
time
82
allow Example of what validation must prevent: RS(T2)={B} RS(T3)={A, B} WS(T2)={B,D} { J WS(T3)={C}
T2
start
T3
start
T2
validated
T3
validated
T2 finish phase 3
T3
start
time
DBMS 2001
83
Another thing validation must prevent: RS(T2)={A} RS(T3)={A,B} WS(T2)={D,E} WS(T3)={C,D} {J

T2
validated
T3
validating finish
BAD: w3(D) w2(D)
T2
time
DBMS 2001
84
allow Another thing validation must prevent: RS(T2)={A} RS(T3)={A,B} WS(T2)={D,E} WS(T3)={C, D} {J
T2
validated finish
T3
validated finish
T2
T2
time
DBMS 2001
85
Validation rules for Tj:

(1) When Tj starts phase 1 (reading DB): Ignore(Tj) n FIN; // Transactions that // do not affect the validation of Tj (2) At Validation of Tj: if Validates(Tj) then VAL n VAL U {Tj}; do the write phase; FIN nFIN U {Tj}; VAL n VAL - {Tj};
Validates(Tj): // returns True if Tj validates

for each U VAL do if ( WS(U) RS(Tj) { or WS(U) WS(Tj) { ) then return False; end for; for each U FIN - Ignore(Tj) do if ( WS(U) RS(Tj) { ) then return False; end for; return True;
Exercise: Validation of U, T, V and W

U: RS(U)={B} WS(U)={D}
2. 1. 3. 4.
start validate finish
W: RS(W)={A,D} WS(W)={A,C}
T: RS(T)={A,B} WS(T)={A,C}
DBMS 2001
V: RS(V)={B} WS(V)={D,E}
88
Validation is useful in some cases: - If interaction among transactions low

" rollbacks rare
- If system resources are plentiful

- slightly more bookkeeping than for locking
- If there are real-time constraints

- causes no delays for transactions
DBMS 2001
89
Summary
Have studied C.C. mechanisms used in practice - 2 PL - Multiple granularity - Validation
DBMS 2001
90

Con Currency

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Con Currency

Încărcat de

Drepturi de autor:

Formate disponibile

Principles of Database Management Systems

Constraint: A=B T2: Read(A) A n Av2 Write(A) Read(B) B n Bv2 Write(B)

250 50 150 150

Same as Schedule D but with new T2

T1 Read(A); A n A+100; Write(A);

Read(A);A n Av1; Write(A); Read(B);B n Bv1; Write(B); Read(B); B n B+100; Write(B);

125 25 125 125

Only look at order of READs and WRITEs

A schedule is serial, if actions of transactions are not interleaved

Could we reorder a schedule into an equivalent serial schedule?

Example: (of swapping non-conflicting actions) Sc=r1(A)w1(A)r2(A)w2(A)r1(B)w1(B)r2(B)w2(B)

However, for Sd: Sd=r1(A)w1(A)r2(A)w2(A)r2(B)w2(B)r1(B)w1(B)

Sd cannot be rearranged into a serial schedule

No cycles Sc is equivalent to a serial schedule (in this case T1,T2)

Precedence graph P(S) (S

- action pi(A) precedes qj(A) in S

Lemma Let S1, S2 be schedules for the

How to enforce serializable schedules?

How to enforce serializable schedules?

lj(A) uj(A) Ti lock table

Rule #1: Well-formed transactions

Lock elements (A) before accessing them

Eventually, release the locks

Schedule F (with simple locking)

Rule #3 Two phase locking (2PL)

All lock requests of a transaction have to precede its unlock requests

Time Growing Phase Shrinking Phase

Schedule G (with 2PL)

l1(A); Read(A) l 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);

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

Neither proceeds: a deadlock

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

So, SH(Ti) <S SH(Tj)

Theorem II Rules #1,2,3 (that is, 2PL)

Ti =... l-S1(A) Ti =... l-X1(A) Request

an S-lock for reading an X-lock for writing

Release the locks eventually

r1(A) ... l-X1(A)

Rule #2 Legal scheduler

no l-Xj(A) for j { i S = ... l-Xi(A) ui(A)

no l-Xj(A) for j { i no l-Sj(A) for j { i

A way to summarize Rule #2

Locks already held by some Ti

True <=> OK to give a new lock of requested kind

Lock types beyond S/X

New request Comp

How does locking work in practice?

Here is one (simplified) way ...

Sample Locking System:

Ti Read(A),Write(B) Scheduler, part I lock table

l(A),Read(A), l(B),Write(B) Scheduler, part II

But use hash table:

Lock info for A

If object not found in hash table, it is unlocked

Lock info for A - example

Element: A Group mode: U Waiting: yes List:

What are the objects we lock?

If we lock small objects (e.g., tuples,fields)

We can have it both ways!!

Example (T1 reads t2, T2 reads R1)

Example (T1 reads t2, T2 writes to t4)

Compatibility of multiple granularity locks Comp Requestor IS IX S X T T F F T F T F F F F F