Transcript Document 7125488

ICS 214B: Transaction Processing and
Distributed Data Management
Lecture 5: Tree-based Concurrency Control
and Validation Currency Control
Professor Chen Li
1
Tree-based Concurrency Control
• all objects accessed
through root,
following pointers
A
B
T1 lock
T1 lock
C
T1 lock
D
E
F
 can we release A lock
if we no longer need A??
ICS214B
Notes 05
2
Idea: traverse like “Monkey Bars”
A
T1 lock
B
T1 lock
T1 lock
C
T1 lock
D
E
ICS214B
F
Notes 05
3
Why does this work?
• Assume all Ti start at root; exclusive lock
• Ti  Tj  Ti locks root before Tj
Root
Q
T i  Tj
• Ti always locks an element before Tj
• Actually works if we don’t always start at root
ICS214B
Notes 05
4
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
ICS214B
Notes 05
5
• Tree-like protocols are used typically for
B-tree concurrency control
Root
E.g., during insert, do not release parent lock, until you
are certain child does not have to split
ICS214B
Notes 05
6
Validation Concurrency Control
Another type of optimistic concurrency control
No locks are needed
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
ICS214B
Notes 05
7
Key idea
• Make validation atomic
• If T1, T2, T3, … is validation order, then
resulting schedule will be conflict
equivalent to Ss = T1 T2 T3...
ICS214B
Notes 05
8
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)
ICS214B
Notes 05
9
Example of what validation must prevent:
RS(T2)={B}
 RS(T3)={A,B} = 
WS(T2)={B,D}
WS(T3)={C}
T2
start
T3
start
T2
validated
T2
finish
BAD: R3(B) W2(B)
T3
Validated?
time
“T3 validated” failed, since T3 starts before T2
finished, and T3 could have read B before T2 wrote
B, violating T2T3
ICS214B
Notes 05
10
allow
Example of what validation must prevent:
RS(T2)={B}
 RS(T3)={A,B} = 
WS(T2)={B,D}
WS(T3)={C}
T2
start
T2
validated
T2
T3
finish
start
T3
Validated
time
ICS214B
Notes 05
11
Another thing validation must prevent:
RS(T2)={A}
RS(T3)={A,B}
WS(T2)={D,E}  WS(T3)={C,D} = 
T2
validated
T3
Validated?
finish
BAD: w3(D) w2(D)
T2
time
“T3 validated” failed, since W3(D) could be before
w2(D), violating T2T3
ICS214B
Notes 05
12
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
ICS214B
Notes 05
time
13
Validation rules for Tj:
Globally: VAL = {};
(1) When Tj starts phase 1:
ignore(Tj)  FIN
(2) at Tj Validation:
if check (Tj) then
[ VAL  VAL U {Tj};
do write phase;
FIN FIN U {Tj} ]
ICS214B
Notes 05
14
Check (Tj):
For Ti  VAL - IGNORE (Tj) DO
IF [ WS(Ti)

RS(Tj)   OR
Ti  FIN ] THEN RETURN false;
RETURN true;
Is this check too restrictive ?
ICS214B
Notes 05
15
Improving Check(Tj)
For Ti  VAL - IGNORE (Tj) DO
IF [ WS(Ti)
(Ti 

RS(Tj)   OR
FIN AND WS(Ti)
 WS(Tj)  )]
THEN RETURN false;
RETURN true;
ICS214B
Notes 05
16
Exercise:
start
validate
finish
U: RS(U)={B}
WS(U)={D}
T: RS(T)={A,B}
WS(T)={A,C}
ICS214B
W: RS(W)={A,D}
WS(W)={A,C}
V: RS(V)={B}
WS(V)={D,E}
Notes 05
17
• U: no condition
• T: OK
– Condition 1: RS(T)  WS(U) = {AB}  {D} = 
– Condition 2: WS(T)  WS(U) = {AC}  {D} = 
• V: OK
– Condition 1: RS(V)  WS(U) = {AD}  {E} =  OK
– Condition 2: WS(V)  WS(T) = {DE}  {AC} =  OK
• W: Not OK
– Condition 1: RS(W)  WS(T) = {AD}  {AC} =  Not OK
ICS214B
Notes 05
18
Validation (also called optimistic
concurrency control) is useful in some
cases:
- Conflicts rare
- System resources plentiful
- Have real-time constraints
ICS214B
Notes 05
19
Summary
Have studied C.C. mechanisms used in
practice
- 2 PL
- Multiple granularity
- Tree (index) protocols
- Validation
ICS214B
Notes 05
20