A distributed transaction coordinates changes across two or more systems, often called resource managers. It must produce one unanimous outcome: every participant commits, or every participant aborts. section 6.0 section 6.4
Think of it as several local transactions joined into one global transaction. Each participant owns private local state, while messages coordinate the participants over the network. A participant may be working, prepared, committed, or aborted; committed and aborted are final states. section 6.1 section 6.2
Transferring money between two stores
One participant subtracts money from an account, while another adds it to a different account. Independent local commits could leave only one change applied. A distributed transaction coordinates both operations so the transfer commits together or aborts together. section 6.1
Judge a distributed transaction by two complementary guarantees:
- Safety prevents conflicting decisions, such as one participant committing while another aborts. section 1.4.1
- Liveness requires every participant eventually to reach a decision, preventing the transaction from remaining stuck. section 1.4.1
- Atomic commit protocols coordinate these guarantees across resource managers. Two-Phase Commit is the best-known protocol: it separates Prepare from Commit, guaranteeing safety and liveness for resource-manager failure but only safety for transaction-coordinator failure. section 6.4
Figure 6.3 A distributed transaction consists of two or more nondistributed transactions.
Use the decomposition diagram to connect one global transaction with its component local transactions. section 6.2
