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 don’t 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)