Distributed Transaction • A distributed transaction accesses resource managers distributed across a network Implementing Distributed • When resource managers are DBMSs we refer to the Transactions system as a distributed database system Chapter 24 DBMS at Site 1 Application Program DBMS 1 at Site 2 2 Distributed Database Systems ACID Properties • Each local DBMS might export • Each local DBMS – stored procedures, or – supports ACID properties locally for each subtransaction – an SQL interface. • Just like any other transaction that executes there • In either case, operations at each site are grouped – eliminates local deadlocks together as a subtransaction and the site is referred • The additional issues are: to as a cohort of the distributed transaction – Global atomicity: all cohorts must abort or all commit – Each subtransaction is treated as a transaction at its site – Global deadlocks: there must be no deadlocks involving • Coordinator module (part of TP monitor) supports multiple sites ACID properties of distributed transaction – Global serialization: distributed transaction must be globally serializable – Transaction manager acts as coordinator 3 4 Atomic Commit Protocol Global Atomicity Transaction (3) xa_reg • All subtransactions of a distributed transaction Manager Resource must commit or all must abort (coordinator) Manager (1) tx_begin (cohort) • An atomic commit protocol, initiated by a (4) tx_commit (5) atomic coordinator (e.g., the transaction manager), commit protocol ensures this. (3) xa_reg Resource Application – Coordinator polls cohorts to determine if they are all Manager program (cohort) willing to commit (2) access • Protocol is supported in the xa interface resources (3) xa_reg between a transaction manager and a resource Resource Manager manager (cohort) 5 6 1 Cohort Abort Atomic Commit Protocol • Most commonly used atomic commit • Why might a cohort abort? protocol is the two-phase commit protocol – Deferred evaluation of integrity constraints • Implemented as an exchange of messages – Validation failure (optimistic control) between the coordinator and the cohorts – Deadlock – Crash of cohort site • Guarantees global atomicity of the – Failure prevents communication with cohort transaction even if failures should occur site while the protocol is executing 7 8 Two-Phase Commit – The Two-Phase Commit -- Phase 1 • When application invokes tx_commit, coordinator Transaction Record sends prepare message to all cohorts • During the execution of the transaction, before the • prepare message (coordinator to cohort) : two-phase commit protocol begins: – If cohort wants to abort at any time prior to or on receipt of the message, it aborts and releases locks – When the application calls tx_begin to start the – If cohort wants to commit, it moves all update records to transaction, the coordinator creates a transaction record mass store by forcing a prepare record to its log for the transaction in volatile memory • Guarantees that cohort will be able to commit (despite crashes) if – Each time a resource manager calls xa_reg to join the coordinator decides commit (since update records are durable) transaction as a cohort, the coordinator appends the • Cohort enters prepared state cohort’s identity to the transaction record – Cohort sends a vote message (“ready” or “aborting”). It • cannot change its mind • retains all locks if vote is “ready” • enters uncertain period (it cannot foretell final outcome) 9 10 Two-Phase Commit -- Phase 1 Two-Phase Commit -- Phase 2 • vote message (cohort to coordinator): Cohort indicates it • Commit or abort message (coordinator to cohort): is “ready” to commit or is “aborting” – If commit message – Coordinator records vote in transaction record • cohort commits locally by forcing a commit record to its log – If any votes are “aborting”, coordinator decides abort and deletes transaction record • cohort sends done message to coordinator – If all are “ready”, coordinator decides commit, forces commit – If abort message, it aborts record (containing transaction record) to its log (end of phase 1) – In either case, locks are released and uncertain period ends • Transaction committed when commit record is durable • done message (cohort to coordinator): • Since all cohorts are in prepared state, transaction can be – When coordinator receives a done message from each committed despite any failures cohort, it writes a complete record to its log and deletes – Coordinator sends commit or abort message to all cohorts transaction record from volatile store 11 12 2 Two-Phase Commit (commit case) Two-Phase Commit (abort case) Application Coordinator Cohort Application Coordinator Cohort tx_commit - send prepare msg to tx_commit - send prepare msg to cohorts in trans. rec. - force prepare cohorts in trans. rec. - force prepare phase 1 rec. to cohort log phase 1 rec. to cohort log - record vote in trans. rec. - send vote msg u - record vote in trans.rec. p - send vote msg n u e p c n r e e c - if all vote ready, force i - if any vote abort, r r e o t i r a d o t i a commit rec. to coord. log delete transaction rec. d n i - send commit msg -force commit - send abort msg - local abort n rec. to cohort log resume - return status - release locks phase 2 - release locks - when all done msgs rec’d, - send done msg xa interface write complete rec. to log - delete trans. rec. xa interface resume - return status 13 14 Distributing the Coordinator Coordinator/Cohort Tree Domain A • A transaction manager controls resource TMA managers in its domain Applic. • When a cohort in domain A invokes a resource RM1 RM2 manager, RMB, in domain B, the local transaction manager, TMA, and remote Domain C transaction manager, TMB, are notified Domain B – TMB is a cohort of TMA and a coordinator of TMB TMC RMB • A coordinator/cohort tree results RM3 RM4 RM5 invocations 15 protocol msgs 16 Distributing the Coordinator Failures and Two-Phase Commit • The two-phase commit protocol progresses • A participant recognizes two failure situations. down and up the tree in each phase – Timeout : No response to a message. Execute a timeout protocol – When TMB gets a prepare msg from TMA it sends a prepare msg to each child and waits – Crash : On recovery, execute a restart protocol – If each child votes ready, TMB sends a ready • If a cohort cannot complete the protocol until msg to TMA some failure is repaired, it is said to be blocked • if not it sends an abort msg – Blocking can impact performance at the cohort site since locks cannot be released 17 18 3 Timeout Protocol Timeout Protocol • Cohort (in prepared state) times out waiting for • Cohort times out waiting for prepare message commit/abort message – Cohort is blocked since it does not know coordinator’s – Abort the subtransaction decision • Since the (distributed) transaction cannot commit unless • Coordinator might have decided commit or abort cohort votes to commit, atomicity is preserved • Cohort cannot unilaterally decide since its decision • Coordinator times out waiting for vote message might be contrary to coordinator’s decision, violating atomicity – Abort the transaction • Locks cannot be released • Since coordinator controls decision, it can force all – Cohort requests status from coordinator; remains blocked cohorts to abort, preserving atomicity • Coordinator times out waiting for done message – Requests done message from delinquent cohort 19 20 Restart Protocol - Cohort Restart Protocol - Coordinator • On restart: • On restart cohort finds in its log – Search log and restore to volatile memory the transaction – begin_transaction record, but no prepare record: record of each transaction for which there is a commit record, • Abort (transaction cannot have committed because cohort has not but no complete record voted) • Commit record contains transaction record – prepare record, but no commit record (cohort crashed in its uncertain period) • On receiving a request from a cohort for transaction • Does not know if transaction committed or aborted status: • Locks items mentioned in update records before restarting system – If transaction record exists in volatile memory, reply based • Requests status from coordinator and blocks until it receives an answer on information in transaction record – commit record – If no transaction record exists in volatile memory, reply abort • Recover transaction to committed state using log • Referred to as presumed abort property 21 22 Presumed Abort Property Presumed Abort Property • If, when a cohort asks for the status of a – The coordinator had crashed and restarted and found a transaction, there is no transaction record in complete record for the transaction in its log coordinator’s volatile storage, either – The coordinator had committed the transaction, – The coordinator had aborted the transaction and deleted received done messages from all cohorts and hence the transaction record deleted the transaction record from volatile memory – The coordinator had crashed and restarted and did not • The last two possibilities cannot occur find the commit record in its log because • It was in Phase 1 of the protocol and had not yet made a – In both cases, the cohort has sent a done message and decision, or hence would not request status • It had previously aborted the transaction • Therefore, coordinator can respond abort – or … 23 24 4 Heuristic Commit Variants/Optimizations • What does a cohort do when in the blocked state and the coordinator does not respond to a request • Read/only subtransactions need not for status? participate