Jinze Liu Tree-based concurrency control Validation concurrency control Example 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?? A B C D EF T 1 lock Assume all T i start at root; exclusive lock T i T j T i locks root before T j Actually works if we dont always start at root Root Q T i T j (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 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 Rules for shared & exclusive locks? A B C D EF T 1 S lock(released) T 1 S lock (held) T 1 X lock (released) T 1 X lock (will get) Rules for shared & exclusive locks? A B C D EF T 1 S lock(released) T 1 S lock (held) T 1 X lock (released) T 1 X lock (will get) T 2 reads: B modified by T 1 F not yet modified by T 1 Need more restrictive protocol Will this work?? Once T 1 locks one object in X mode, all further locks down the tree must be in X mode 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 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... 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) 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 RS(T 2 )={B} RS(T 3 )={A,B} WS(T 2 )={B,D} WS(T 3 )={C} T 2 finish phase 3 time T 2 start T 2 validated T 3 validated T 3 start allow T 3 start 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) finish T 2 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 (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 } ] Check (Tj): For Ti VAL - IGNORE (Tj) DO IF [ WS(Ti) RS(Tj) OR Ti FIN ] THEN RETURN false; RETURN true; For Ti VAL - IGNORE (Tj) DO IF [ WS(Ti) RS(Tj) OR (Ti FIN AND WS(Ti) WS(Tj) )] THEN RETURN false; RETURN true; 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 Validation (also called optimistic concurrency control) is useful in some cases: - Conflicts rare - System resources plentiful - Have real time constraints Have studied C.C. mechanisms used in practice - 2 PL - Multiple granularity - Tree (index) protocols - Validation Concurrency control Serial schedule: no interleaving Conflict-serializable schedule: no cycles in the precedence graph; equivalent to a serial schedule 2PL: guarantees a conflict-serializable schedule Strict 2PL: also guarantees recoverability Recovery: undo/redo logging with fuzzy checkpointing Normal operation: write-ahead logging, no force, steal Recovery: first redo (forward), and then undo (backword)