Distributed DBMSPage © 1998 M. Tamer Özsu & Patrick Valduriez Outline Introduction Background Distributed DBMS Architecture Distributed Database Design Distributed Query Processing Distributed Transaction Management  Transaction Concepts and Models  Distributed Concurrency Control  Distributed Reliability n Building Distributed Database Systems (RAID) Mobile Database Systems Privacy, Trust, and Authentication Peer to Peer Systems

Distributed DBMSPage © 1998 M. Tamer Özsu & Patrick Valduriez Arise due to non-atomicity of log and message send actions Coordinator site fails after writing “begin_commit” log and before sending “prepare” command  treat it as a failure in WAIT state; send “prepare” command Participant site fails after writing “ready” record in log but before “vote-commit” is sent  treat it as failure in READY state  alternatively, can send “vote-commit” upon recovery Participant site fails after writing “abort” record in log but before “vote-abort” is sent  no need to do anything upon recovery 2PC Recovery Protocols –Additional Cases (see book)

Distributed DBMSPage © 1998 M. Tamer Özsu & Patrick Valduriez Coordinator site fails after logging its final decision record but before sending its decision to the participants  coordinator treats it as a failure in COMMIT or ABORT state  participants treat it as timeout in the READY state Participant site fails after writing “abort” or “commit” record in log but before acknowledgement is sent  participant treats it as failure in COMMIT or ABORT state  coordinator will handle it by timeout in COMMIT or ABORT state 2PC Recovery Protocols –Additional Case (see book)

Distributed DBMSPage © 1998 M. Tamer Özsu & Patrick Valduriez Problem With 2PC Blocking  Ready implies that the participant waits for the coordinator  If coordinator fails, site is blocked until recovery  Blocking reduces availability Independent recovery is not possible However, it is known that:  Independent recovery protocols exist only for single site failures; no independent recovery protocol exists which is resilient to multiple-site failures. So we search for these protocols – 3PC

Distributed DBMSPage © 1998 M. Tamer Özsu & Patrick Valduriez 3PC is non-blocking. A commit protocols is non-blocking iff  it is synchronous within one state transition, and  its state transition diagram contains  no state which is “adjacent” to both a commit and an abort state, and  no non-committable state which is “adjacent” to a commit state Adjacent: possible to go from one stat to another with a single state transition Committable: all sites have voted to commit a transaction  e.g.: COMMIT state Three-Phase Commit

Distributed DBMSPage © 1998 M. Tamer Özsu & Patrick Valduriez State Transitions in 3PC INITIAL WAIT Commit command Prepare Vote-commit Prepare-to-commit Coordinator Vote-abort Global-abort ABORT COMMIT PRE- COMMIT Ready-to-commit Global commit INITIAL READY Prepare Vote-commit Prepared-to-commit Ready-to-commit Prepare Vote-abort Global-abort Ack Participants COMMIT ABORT PRE- COMMIT Global commit Ack

Distributed DBMSPage © 1998 M. Tamer Özsu & Patrick Valduriez Communication Structure (see book) C P P P P C P P P P C ready?yes/no pre-commit/ pre-abort? commit/abort Phase 1Phase 2 P P P P C yes/no ack Phase 3

Distributed DBMSPage © 1998 M. Tamer Özsu & Patrick Valduriez Formalism for Commit Protocols Finite set of states Messages addressed to the site Messages sent by the site Initial state Abort states Commit states Q Q V Q Q : Q Q

Distributed DBMSPage © 1998 M. Tamer Özsu & Patrick Valduriez Formalism for Commit Protocols Properties: Protocols are non-deterministic: Sites make local decisions. Messages can arrive in any order V V

Distributed DBMSPage © 1998 M. Tamer Özsu & Patrick Valduriez Global State Definition Global state vector containing the states of the local protocols. Outstanding messages in the network A global state transition occurs whenever a local state transition occurs at a participating site. Exactly one global transition occurs for each local transition.

Distributed DBMSPage © 1998 M. Tamer Özsu & Patrick Valduriez Global Sate Graph Global state is inconsistent if its state vector contains both a commit and abort state. q 1 q 2 xact req w 1 q 2 start xact w 1 w 2 yes w 1 a 2 no a 1 w 2 abort c 1 w 2 commit a 1 a 2 c 1 c 2

Distributed DBMSPage © 1998 M. Tamer Özsu & Patrick Valduriez Two states are potentially concurrent if there exists a reachable global state that contains both local states. Concurrency set of s is set of all local states that are potentially concurrent with it. C(s) C(w 1 ) = { V 2, a 2, w 2 } The sender set for s, S(s) = {t/t sends message m & m  M} where M be the set of messages that are received by s. t is a local state.

Distributed DBMSPage © 1998 M. Tamer Özsu & Patrick Valduriez States of Various States in the Commit Protocol Global state inconsistent if it contains both  local commit state  local abort state Final state if  All local states are final Terminal state if:  there exists an immediately reachable successor state   deadlock Committable state (local) if:  all sites have voted yes on committing the transaction Otherwise, non-committable

Distributed DBMSPage © 1998 M. Tamer Özsu & Patrick Valduriez An Example when Only a Single Site Remains Operational This site can safely abort the transaction if and only if the concurrency set for its local state does not contain a commit state This site can safely commit only if  Its local state must be “committable”  And the concurrency set for its state must not contain an abort state. A blocking situation arises when  The concurrency set for the local state contains both a commit and an abort state  Or the site is in a “noncommittable” state and the concurrency set for that state contains a commit state  The site can not commit because it can not infer that all sites have voted yes on committing  It can not abort because another site may have committed the transaction before crashing. There observations imply the simple but power result in the next slide

Distributed DBMSPage © 1998 M. Tamer Özsu & Patrick Valduriez Fundamental Non-blocking Theorem Definition : protocol is synchronous within one state transition if one site never leads another site by more than one state transition. Theorem Fundamental non-blocking: A protocol is non- blocking iff  There exists no local state s C(s) = A (abort) and C (commit)  And there exists no non-committable state s C(s) = C (commit) Lemma : A protocol that is synchronous within one state transition is non-blocking iff:  No local state is adjacent to both a commit & an abort state  No non-committable state is adjacent to a commit state

Distributed DBMSPage © 1998 M. Tamer Özsu & Patrick Valduriez Three-Phase Commit Protocol Site i (i = 2,3,…n) (slave) cici aiai wiwi qiqi xact i no i xact i yes i … abort i commit i pipi prepare i ack i p1p1 a1a1 q1q1 w1w1 c1c1 ack 2 ack n commit 2 commit n … … … request xact 2 xact 4 … … no 2 | |no n abort 2 abort n … … yes 2 yes n prepare 2 prepare n Site I (co-ordinator)