Chapter 6: Distributed transactions

Introduction

Introduces distributed transactions as changes spanning multiple systems, defines their participants, and previews the chapter’s treatment of Two-Phase Commit.

• Distributed transaction participants: Explain that a distributed transaction spans changes across multiple systems and that its participants are called resource managers (RMs). State that RMs can include databases and other systems, such as message queues.
  Why it matters: Identifying the participants makes the later discussion of coordinating a transaction across systems easier to follow.
• Two-Phase Commit chapter roadmap: Describe that the chapter will cover the concept of distributed transactions, Two-Phase Commit both without and with failures, and possible improvements to that protocol.
  Why it matters: This roadmap shows which aspects of Two-Phase Commit the chapter will examine.

Key terms: distributed transaction, resource manager, RM, database system, message queuing system, Two-Phase Commit protocol, absence of failure, presence of failure, improvements

6.1 Atomic commitment: From a single RM to multiple RMs

This section uses a money transfer to show why atomic commitment across multiple resource managers requires coordination rather than a single manager’s local commit.

• Atomic transaction outcomes: Explain that a transaction ends in exactly one commit or abort: a commit makes its operations observably equivalent to executing once, while an abort makes them observably equivalent to not executing at all.
  Why it matters: These outcomes define what a distributed commit must preserve.
• Cross-manager commit coordination: Explain why transferring money between accounts on two resource managers creates a coordination problem: each manager controls only its local state, so separate subtransactions must agree to both commit or both abort. Contrast a single manager’s local-state writes with the atomic commit protocols needed across managers.
  Why it matters: Coordinating the two outcomes is what makes the combined transfer a transaction rather than two unrelated transactions.

Key terms: transaction, atomic, commit, abort, resource manager, RM, subtransaction, completeness, atomic commit protocols, local state

6.1.1 Transaction on a single RM

A transaction on one resource manager achieves atomic commitment through a single local commit-or-abort write, with an unwritten decision treated as an abort after failure.

• Single-RM atomic commitment: Explain how a single RM commits or aborts a transaction with one atomic write of a commit or abort entry to its local state, and what happens if it fails before that write.
  Why it matters: This local decision is the baseline for understanding why commitment across multiple RMs is harder.

Key terms: RM, atomicity, atomic write, commit entry, abort entry, local state

6.1.2 Transaction on multiple RMs

This section explains how atomic commit keeps a transaction across multiple resource managers all-or-nothing and defines its safety and liveness guarantees.

• Atomic commitment across RMs: Explain that an atomic commit protocol guarantees atomicity for a distributed transaction spanning multiple resource managers (RMs): their subtransactions unanimously commit or abort.
  Why it matters: A distributed transaction is atomic only if its participating RMs reach a consistent outcome.
• Safety and liveness guarantees: Distinguish the protocol's safety guarantee, which forbids conflicting commit and abort decisions by participants, from its liveness guarantee, which says every participant eventually reaches a permanent commit or abort decision.
  Why it matters: These guarantees state separately what must never go wrong and what must eventually happen.

Key terms: distributed transaction, RM, atomic commit protocol, subtransaction, atomicity, safety, liveness, participant, commit state, abort state

6.1.3 Blocking and nonblocking

This subsection distinguishes blocking from nonblocking atomic commit protocols by what they guarantee when a participant fails.

• Blocking and nonblocking commits: Distinguish blocking and nonblocking atomic commit protocols by their guarantees in the presence of participant failure. Explain that a nonblocking protocol lets the remaining participants decide to commit or abort despite one participant’s failure.
  Why it matters: This distinction shows whether a participant failure can leave the others unable to decide the transaction’s outcome.

Key terms: atomic commit protocols, blocking, nonblocking, safety, liveness, participant failure

6.2 The essence of distributed transactions

This section gives a state-based mental model for reasoning about distributed transactions and atomic commit protocols.

• Global and local transactions: Explain that a distributed, or global, transaction consists of two or more nondistributed, or local, transactions.
  Why it matters: This identifies the separate transactions whose outcomes an atomic commit protocol must coordinate.
• Local transaction state transitions: Describe the working, prepared, committed, and aborted states of a local transaction, including how it can move between them and which states are final.
  Why it matters: These transitions provide the vocabulary for explaining what atomic commit can still decide at each point.
• Global transaction state vector: Explain that the state of a distributed transaction includes both the states of its local transactions and the outstanding messages in the network.
  Why it matters: Looking only at local states would leave out messages that matter when reasoning about protocol behavior and failures.

Key terms: distributed transaction, global transaction, nondistributed transaction, local transaction, working, prepared, committed, aborted, state vector, outstanding messages

6.3 Two-Phase Commit protocol

Introduces Two-Phase Commit as a blocking atomic commit protocol by contrasting its guarantees with and without participant failure.

• Two-Phase Commit failure guarantees: Explain that Two-Phase Commit (2PC) guarantees both safety and liveness without participant failure, but with even one particular participant failure it guarantees safety while liveness is not necessarily guaranteed, making it a blocking atomic commit protocol.
  Why it matters: This distinction explains why a protocol can remain safe yet leave a transaction unable to finish.

Key terms: Two-Phase Commit (2PC), atomic commit protocol, safety, liveness, blocking

6.3.1 In the absence of failure

This section traces a failure-free Two-Phase Commit execution, from the client’s request through the resource managers’ votes and the coordinator’s final decision.

• Coordinator and participant roles: Describe how a client starts transactions and performs reads and writes at each participating resource manager (RM), then asks the single transaction coordinator (TC)—rather than the RMs directly—to commit or abort them.
  Why it matters: These roles explain who starts 2PC and who coordinates its outcome.
• Prepare phase votes and logs: Trace the Prepare phase: the TC persistently logs ⟨Prepare, Timeout⟩ and requests preparation from every RM; each RM either logs and sends ⟨Vote-to-Commit⟩ or logs and sends ⟨Abort⟩ and aborts locally. Explain why these responses are asymmetric: an RM may abort on its own but may not commit on its own.
  Why it matters: Preparation gathers each participant’s position without letting one participant commit independently.
• Commit phase decision rule: Explain that the TC logs and sends Commit only after every RM votes to commit; one Abort response or a timeout instead makes it log and send Abort. Describe how each RM then logs the received decision and commits or aborts its local transaction.
  Why it matters: The all-votes rule gives the participating RMs one coordinated final outcome.

Key terms: client, transaction coordinator (TC), resource manager (RM), 2PC, Prepare, ⟨Prepare, Timeout⟩, ⟨Vote-to-Commit⟩, ⟨Abort⟩, Commit, Abort

6.3.2 In the presence of failure

This section explains how two-phase commit recovers from resource manager failures but can block when the transaction coordinator fails.

• Resource manager recovery paths: Describe how an RM recovers according to the last decision it persistently recorded: no vote or abort, a vote to commit, commit, or abort.
  Why it matters: The durable log entry determines what an RM can safely do after restarting.
• Coordinator failure and blocking: Explain why two-phase commit preserves safety but may lose liveness when the TC fails, using the case where one RM has been told to commit while another has voted to commit but has not received the decision.
  Why it matters: A participant cannot safely guess the transaction outcome when the coordinator disappears.
• Failure model and guarantees: State the section’s partially synchronous failure model and contrast the guarantees: without failure two-phase commit has safety and liveness; RM failure does not block it, but TC failure may.
  Why it matters: The failure assumptions explain why the guarantee depends on which component fails.

Key terms: RM, Vote-to-Commit, Abort, Commit, REDO, UNDO, TC, safety, liveness, blocked

6.3.3 Improvement

This section shows how participant-to-participant communication can reduce blocking in Two-Phase Commit, but why it cannot always resolve an undecided transaction safely.

• Participant consultation after coordinator failure: Explain how a resource manager stuck after persistently recording ⟨Vote-to-Commit⟩ can consult other resource managers if the transaction coordinator fails, and safely follow one that has already committed or aborted.
  Why it matters: Consulting another participant can resolve some executions that would otherwise block.
• Remaining blocking and timeout hazard: Explain why peer consultation still leaves a blocking case when all resource managers voted to commit but none received a commit or abort request, and why timing out and aborting can conflict with a later commit sent by the recovered coordinator.
  Why it matters: Reducing blocking does not justify a timeout rule that lets participants reach conflicting outcomes.

Key terms: TC, RM, ⟨Vote-to-Commit⟩, ⟨Commit⟩, ⟨Abort⟩, blocking executions, safety violation, timeout window

6.4 Summary

This summary connects local transactions to distributed atomic commitment and recaps the guarantees and failure limits of Two-Phase Commit.