A resource manager (RM) is a component that manages a transactional resource and executes the local transaction for that resource. Database systems are common RMs, but message queuing systems can also participate. section 6.0
A distributed transaction combines local transactions executed by multiple RMs. Each RM controls its own local state, while an atomic commit protocol coordinates a unanimous commit or abort decision across them. section 6.1 section 6.4
A transfer across two resource managers
Suppose RM1 hosts the source account and RM2 hosts the target account. RM1 performs the debit and RM2 performs the credit. Without coordination, one local transaction could commit while the other aborts. Two-Phase Commit instead asks both RMs to prepare, then directs both to commit or abort. section 6.1 section 6.3.1
In Two-Phase Commit, each resource manager:
- Executes ordinary reads and writes for its local transaction. section 6.3.1
- Votes to commit only after persistently recording its readiness; otherwise it records and reports an abort. section 6.3.1
- Records and performs the coordinator’s final commit or abort decision. section 6.3.1
- Recovers according to its durable log: it aborts, consults the coordinator, redoes a commit, or undoes an abort. section 6.3.2
Listing 6.2 Money transfer on two RMs executing in two transactions
RM1: BEGIN UPDATE accounts SET balance = balance - $1 WHERE id = $2; COMMIT RM2: BEGIN UPDATE accounts SET balance = balance + $1 WHERE id = $3; COMMIT
Compare the two independent local transactions involved when a transfer spans RM1 and RM2. section 6.1
RMs remain safe when failures occur: they do not produce conflicting final outcomes. Two-Phase Commit can remain live after an RM failure, but a failed transaction coordinator can block an RM that has voted to commit. section 6.3.2 section 6.4
