CS 603 Handling Failure in Commit February 20, 2002

Two-Phase Commit (Lamport ’76, Gray ’79) Central coordinator initiates protocol –Phase 1: Coordinator asks if participants can commit Participants respond yes/no –Phase 2: If all votes yes, coordinator sends Commit Participants respond when done Blocks on failure –Participants must replace coordinator –If participant and coordinator fail, wait for recovery While blocked, transaction must remain Isolated –Prevents other transactions from completing

Formal Recovery Models (Skeen & Stonebraker ’83) Formal models for commit protocols –Transaction state –Failure Protocol types –Commit –Termination –Recovery Necessary Conditions for non-blocking –Leads to Three-Phase Protocol

Background Transaction has “commit point” –Failure after  transaction visible –Failure before  abort as part of recovery Protocol needed to ensure commit/abort decision unanimous –Any site can abort before first site commits –No site can abort after first site commits Non-Blocking Protocol: Failure doesn’t cause operational sites to suspend

Transaction Model Network: –Point to point communication –Maximum delay T or timeout If timeout, sender can assume recipient of network failure If network failure, sender doesn’t know if message received Each site can be viewed as Finite State Automaton –Sites have three state “classes”: Initial: Allowed to abort the transaction Abort: Can’t transition to non-abort Commit: Can’t transition to non-commit –Nondeterministic with respect to protocol, i.e., State transitions may occur independent of protocol due to local actions –State diagram is acyclic (assures termination) –Site transitions asynchronous –State transitions atomic

State Transition Graph for Two-Phase Commit c1c1 a1a1 c2c2 a2a2 q1q1 w1w1 p2p2 q2q2 xact request/ start xact no/ - start xact/ no start xact/ yes commit/ - abort/ - yes/ abort yes/ commit CoordinatorParticipant

Transaction Model Global Transaction State –Vector of local states –Outstanding messages in the network –Final if all local states in final state –Inconsistent if vector contains both commit and abort states –Global state transition occurs when local state transition occurs Reachable State Graph –Possible global transitions –Protocol correct if and only if reachable state graph has: No inconsistent states All terminal states are final states Local states potentially concurrent if a reachable global state contains both local states –Concurrency set C(s) is all states potentially concurrent with s Sender set S(s) = {local states t | t sends m and s can receive m}

Reachable Global State Graph for Two-Phase Commit Leaf nodes are terminal states –All contain only final states No nodes have both “abort” and “commit” –Protocol consistent Therefore 2-phase commit is operationally correct

Failure Models Site failure assumed when expected message not received in time –Modeled as “failure transition” Assumption: A site knows it has failed –Allow multiple failure transitions from a state Different types of failure Independent Recovery –Transition directly to final state without communication –Paper discusses only two site case

Single Site Failure Lemma 1: If a protocol contains a local state s with both abort and commit in C(s), cannot independently recover –C(s) has both abort and commit –s cannot fail to either abort or commit 2PC: C(p 2 ) has both commit and abort! Rule 1: If C(s) has commit, insert failure transition from s to commit, else insert failure from s to abort

Modified 2PC with Rule 1 c1c1 a1a1 c2c2 a2a2 q1q1 w1w1 p2p2 q2q2 xact request/ start xact no/ - start xact/ no start xact/ yes commit/ done abort/ - yes/ abort yes/ commit CoordinatorParticipant p1p1 done/ -

Handling Timeout Rule 2: For each intermediate state s –if t is in S(s) and t had a failure transition to a commit (abort) state, then –assign a timeout transition from s to a commit (abort) state Assumption: Failed state will independently recover –Rule 1 forces transition to commit / abort –Rule 2 forces “live” transaction to do same

Modified 2PC with Rules 1,2 c1c1 a1a1 c2c2 a2a2 q1q1 w1w1 p2p2 q2q2 xact request/ start xact no/ - start xact/ no start xact/ yes commit/ done abort/ - yes/ abort yes/ commit CoordinatorParticipant p1p1 done/ -

Theorem: Sufficient Conditions for Handling Failure Rules 1 and 2 are sufficient for designing protocols resilient to a single site failure Proof: Let P be protocol s.t. there is no s where C(s) contains commit and abort –P’ is P modified by Rules 1 and 2 –Site 1 fails in state s 1 when Site 2 in s 2 Transitions to f 1 inconsistent with f 2 Case 1: Site t 2 in final state f 2 –Implies f 2 in C(s 1 ) – violates Rule 1 Case 2: Site 2 in nonfinal state, timeouts to f 2 –Implies s 1  S(s 2 ) – violates Rule 2

Two site failure Theorem: No protocol using independent recovery resilient to arbitrary two site failures –Holds only if failures concurrent (both sites fail without knowing other has failed) Proof: Assume path in global state graph G 0, …, G m, all sites recover to abort from G 0, to commit from G m Let G k be first state where first site j recovers to commit –j recovers to abort in G k-1 –j was only site to transition between G k and G k-1 –All other sites will recover same in G k and G k-1 –So either G k or G k-1 inconsistent if j and another site fail Key: No non-blocking recovery –Doesn’t mean operational sites have to block