1 ICS 214B: Transaction Processing and Distributed Data Management Lecture 5: Tree-based Concurrency Control and Validation Currency Control Professor Chen Li

ICS214BNotes 052 Tree-based Concurrency Control A B C D EF all objects accessed through root, following pointers T 1 lock  can we release A lock if we no longer need A??

ICS214BNotes 053 Idea: traverse like “Monkey Bars” A B C D EF T 1 lock

ICS214BNotes 054 Why does this work? Assume all T i start at root; exclusive lock T i  T j  T i locks root before T j Ti always locks an element before Tj Actually works if we don’t always start at root Root Q T i  T j

ICS214BNotes 055 Rules: tree protocol (exclusive locks) (1) First lock by T i may be on any item (2) After that, item Q can be locked by T i only if parent(Q) locked by T i (3) Items may be unlocked at any time (4) After T i unlocks Q, it cannot relock Q

ICS214BNotes 056 Tree-like protocols are used typically for B-tree concurrency control E.g., during insert, do not release parent lock, until you are certain child does not have to split Root

ICS214BNotes 057 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

ICS214BNotes 058 Key idea Make validation atomic If T 1, T 2, T 3, … is validation order, then resulting schedule will be conflict equivalent to S s = T 1 T 2 T 3...

ICS214BNotes 059 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)

ICS214BNotes 0510 Example of what validation must prevent: RS(T 2 )={B} RS(T 3 )={A,B} WS(T 2 )={B,D} WS(T 3 )={C} time T 2 start T 2 validated T 3 Validated? T 3 start  =  “T3 validated” failed, since T3 starts before T2 finished, and T3 could have read B before T2 wrote B, violating T2  T3 T 2 finish BAD: R3(B) W 2 (B)

ICS214BNotes 0511 Example of what validation must prevent: RS(T 2 )={B} RS(T 3 )={A,B} WS(T 2 )={B,D} WS(T 3 )={C}  =  allow time T 2 start T 2 validated T 3 Validated T 3 start T 2 finish

ICS214BNotes 0512 Another thing validation must prevent: RS(T 2 )={A} RS(T 3 )={A,B} WS(T 2 )={D,E} WS(T 3 )={C,D} time T 2 validated T 3 Validated? finish T 2 BAD: w 3 (D) w 2 (D) “T3 validated” failed, since W3(D) could be before w2(D), violating T2  T3  = 

ICS214BNotes 0513 finish T 2 Another thing validation must prevent: RS(T 2 )={A} RS(T 3 )={A,B} WS(T 2 )={D,E} WS(T 3 )={C,D} time T 2 validated T 3 validated allow finish T 2  = 

ICS214BNotes 0514 Validation rules for T j : Globally: VAL = {}; (1) When T j starts phase 1: ignore(T j )  FIN (2) at T j Validation: if check (T j ) then [ VAL  VAL U {T j }; do write phase; FIN  FIN U {T j } ]

ICS214BNotes 0515 Check (T j ): For T i  VAL - IGNORE (T j ) DO IF [ WS(T i )  RS(T j )   OR T i  FIN ] THEN RETURN false; RETURN true; Is this check too restrictive ?

ICS214BNotes 0516 Improving Check(T j ) For T i  VAL - IGNORE (T j ) DO IF [ WS(T i )  RS(T j )   OR ( T i  FIN AND WS(T i )  WS(T j )   )] THEN RETURN false; RETURN true;

ICS214BNotes 0517 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} start validate finish

ICS214BNotes 0518 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

ICS214BNotes 0519 Validation (also called optimistic concurrency control) is useful in some cases: - Conflicts rare - System resources plentiful - Have real-time constraints

ICS214BNotes 0520 Summary Have studied C.C. mechanisms used in practice - 2 PL - Multiple granularity - Tree (index) protocols - Validation