Distributed Transactions and Commit Protocols

Introduction

A distributed transaction is a logical unit of work whose operations affect resources managed by two or more independent database participants. Examples include transferring money between banks, reserving inventory while creating an order, and updating a customer record together with an accounting ledger. Unlike a local transaction, a distributed transaction must coordinate sites connected by a network, each of which may fail independently and may not share a single clock, process, or storage system.

The central problem is atomic commitment: all required participants must make the same final decision—commit or abort—even when messages are delayed, processes crash, or a coordinator becomes unavailable. Commit protocols provide this agreement, while transaction managers maintain state, enforce isolation, recover from failures, and expose a usable programming interface.

Learning Objectives

After studying this chapter, a student should be able to:

• explain global transactions and distributed ACID properties;
• distinguish transaction managers, resource managers, coordinators, and participants;
• describe two-phase commit (2PC), three-phase commit (3PC), and presumed-commit optimization;
• analyze blocking, failure, logging, timeout, and recovery behavior;
• design saga and compensation-based workflows for long-running operations; and
• select a protocol according to consistency, latency, availability, and business requirements.

1. Global Transactions and the ACID Model

A global transaction is identified by a globally unique transaction identifier and consists of subtransactions or participant branches. A branch executes at one resource manager, such as a relational database, message broker, or inventory service. The global transaction manager coordinates their outcome.

The ACID properties require careful interpretation in a distributed setting:

Atomicity is the distinctive coordination challenge. Local durability at each site does not guarantee global atomicity: one site may commit before another reports failure. Isolation also becomes harder because locking, timestamps, snapshots, or serialization decisions may span sites. A distributed transaction can be locally valid at every site and nevertheless violate a global invariant.

A useful distinction is between serializability and atomic commitment. Serializability concerns the order and visibility of concurrent transactions; atomic commitment concerns whether one transaction takes effect everywhere. A system may provide atomic commit without serializable execution, or serializable local schedules without global atomicity.

2. Architecture and Roles

A common architecture contains four logical roles:

1. Application or transaction initiator requests work.
2. Transaction manager (TM) creates the global transaction, assigns an identifier, tracks branches, and initiates completion.
3. Coordinator runs the commit protocol, collects votes, records the decision, and distributes it. In some systems the TM and coordinator are the same component.
4. Resource managers (RMs) execute branches, maintain logs and locks, and respond to prepare and commit requests.

A participant is prepared when it has completed the branch’s work, forced the necessary recovery information to stable storage, and promised that it can commit after a later decision. Preparation is therefore stronger than “the SQL statements succeeded.” It normally requires retaining locks and sufficient log information for recovery.

Transaction context propagation is essential. A service call must carry the global transaction identifier and branch information; otherwise a downstream operation may execute outside the intended atomic unit. Context propagation across asynchronous queues is especially difficult because message delivery, retry, and duplicate suppression must be defined explicitly.

3. Two-Phase Commit

Two-phase commit is the classic atomic-commit protocol. It assumes reliable stable storage and a failure model in which participants and the coordinator may crash and later recover. It does not, by itself, solve network partition or Byzantine failures.

Phase 1: Prepare or voting

The coordinator sends PREPARE. Each participant:

• completes local validation and constraint checks;
• writes a prepare record and required undo/redo information to durable storage;
• holds locks or equivalent isolation resources; and
• replies YES if it can commit, or NO if it must abort.

A participant that votes YES must be able to commit without receiving additional application data. It may not later unilaterally abort merely because a timeout occurs.

Phase 2: Decision

The coordinator decides commit if and only if every required participant votes YES. Formally, for participants P₁ through Pₙ:

If at least one vote is NO, or a participant is known to have failed before preparing, the decision is ABORT. The coordinator writes the global decision durably before sending the decision to participants. Participants then record and execute COMMIT or ABORT, release resources, and acknowledge completion.

The formula assumes a fixed participant set, reliable interpretation of votes, and a protocol run that has reached a valid voting decision. It does not imply that a coordinator can safely decide after an arbitrary timeout.

Figure: The prepare vote precedes a single global decision in two-phase commit.

Correctness and the blocking problem

2PC achieves atomicity because a participant that votes YES cannot safely make an independent choice. If the coordinator fails after participants have prepared but before they receive the decision, those participants enter an uncertain state. They must retain locks and wait for recovery or information from another participant. This is the blocking problem.

A timeout is not equivalent to an abort in standard 2PC. Aborting locally could create a split decision if the coordinator had already recorded COMMIT. Recovery therefore uses durable logs, coordinator inquiries, replicated coordinator state, or presumed outcomes. 2PC is safe under its assumptions but can reduce availability and increase lock duration.

Message and latency considerations

In a failure-free execution, 2PC requires a prepare request and vote response, followed by a decision request and acknowledgement. Thus, from coordinator perspective, it requires two communication phases, although the exact message count depends on multicast and acknowledgement design. Network delay, forced log writes, participant contention, and recovery retries determine actual latency; no universal throughput formula applies.

4. Three-Phase Commit

Three-phase commit inserts an intermediate pre-commit phase between voting and final commit:

1. CanCommit? Participants vote YES or NO.
2. PreCommit is sent after all YES votes; participants acknowledge that they are ready to commit.
3. DoCommit completes the decision.

The protocol attempts to avoid indefinite blocking by ensuring that states are more distinguishable and by using timeouts under a stronger timing and failure model. In particular, participants can sometimes infer a safe action from the protocol state. However, 3PC is not a universal improvement. It requires assumptions such as bounded communication delays, bounded failure detection, and suitable non-partitioned operation. Under network partitions or asynchronous communication, the fundamental coordination limitations remain. It also adds messages, logging, and state-machine complexity.

2PC is commonly preferred when strict atomicity and mature recovery integration matter more than nonblocking behavior. 3PC is relevant mainly in systems whose timing and failure assumptions can be justified; it should not be selected merely because it has “three” phases.

5. Presumed Commit and Related Optimizations

Presumed commit is a logging and message optimization, not a different atomicity principle. It assumes that commit is the common or default outcome. The coordinator records less information for commit and may omit some commit-related acknowledgements or log records. Abort, being the less presumed outcome, requires explicit information.

The complementary presumed abort optimization treats abort as the default and optimizes that path. The choice depends on workload, recovery design, and the cost of retaining transaction records. A presumed outcome must never be confused with an outcome that is safe to infer before the protocol has established it. Optimizations reduce storage or messages; they do not remove the need for a durable, globally consistent decision.

6. Failure, Recovery, and Operational Design

Important failure cases include:

• Participant fails before voting: the coordinator can normally abort, provided no YES decision has been established.
• Participant fails after YES: it must recover its prepare record and learn the global decision; it cannot simply forget the transaction.
• Coordinator fails before decision: participants may remain blocked in 2PC.
• Coordinator fails after durable decision: a recovering coordinator must resend the same decision, never create a new one.
• Lost or duplicated messages: protocol messages need durable identifiers and idempotent handling.
• Network partition: timeout-based guesses can violate atomicity; safe systems distinguish uncertainty from abort.

Recovery records should contain the transaction identifier, participant or branch identity, local state, and global decision when known. Log writes must obey the system’s durability guarantees. Operational monitoring should expose prepared transactions, age of in-doubt transactions, lock retention, retry counts, and recovery backlog.

A practical design should define: maximum transaction duration, participant discovery rules, deadlock behavior, retry and idempotency policy, compensation procedures, administrative resolution authority, and what happens when a participant is permanently lost. Manual “force commit” or “force abort” is a governance decision with possible business inconsistency, not an ordinary timeout action.

7. Sagas and Compensation-Based Workflows

A saga decomposes a long-running business transaction into a sequence of local transactions. Each forward action Tᵢ has a compensating action Cᵢ intended to semantically undo its business effect. If a later step fails, compensations are executed in reverse order for completed steps:

This sequence assumes that compensation is defined for each completed action and that reverse ordering is appropriate. Compensation is not a time machine: it may create a new business event rather than erase history. For example, refunding a payment does not remove the fact that a payment was made, and cancellation of shipment may be impossible after dispatch.

Two common saga styles are:

• Orchestration: a central saga coordinator directs each step and records progress.
• Choreography: services publish events and independently react to them.

Sagas usually release local locks quickly and therefore improve availability and scalability for long workflows. Their trade-off is temporary inconsistency, more complex failure handling, and the need for idempotent commands, durable workflow state, retry policies, deadlines, and reconciliation. They are suitable for order fulfillment, travel booking, claims processing, and provisioning. They are unsuitable when an invariant must never be externally violated and no valid compensation exists.

A robust compensation design specifies the business meaning of reversal, authorization, ordering, retry safety, duplicate-event handling, and irreversibility. The outbox pattern can make publication of a local event atomic with the local database update; inbox or deduplication mechanisms can make event consumption repeat-safe. These patterns improve reliability but do not turn a saga into distributed serializability.

8. Choosing Between 2PC, 3PC, and Sagas

Selection should begin with the business invariant, not the fashionable technology. If “debit and credit must commit together” is a strict invariant across compatible resource managers, 2PC may be justified. If the workflow spans independent services and actions can be reversed or corrected, a saga is often more practical. 3PC should be considered only after its system model has been demonstrated.

9. Applied Case: Illustrative Order and Payment Workflow

Background. An online retailer receives an order, reserves inventory, authorizes payment, and requests shipment. Inventory and payment are managed by separate services, and shipment may take hours.

Problem. A single 2PC transaction would hold resources across slow, independently operated services. Payment authorization may expire, shipment may become unavailable, and not every service supports a common transaction manager.

Analysis. The business does not require shipment and payment to be physically committed in one database transaction, but it does require that an order not remain silently marked as confirmed when payment fails. Payment authorization is also not equivalent to capture, and inventory reservation has an expiry.

Approach. An orchestrated saga creates an order in PENDING state, reserves inventory, requests payment authorization, and then confirms the order. If authorization fails, it releases inventory. If shipment creation fails, it cancels or refunds payment according to the payment provider’s rules and releases inventory. Each command carries an idempotency key. The order state and an outgoing event are written together using an outbox. A reconciliation job finds expired reservations, missing callbacks, and orders stuck in intermediate states.

Outcome. Local locks are short-lived and services remain independently deployable. Customers may briefly see PENDING rather than CONFIRMED, and compensation may produce a refund event rather than erase the original charge. The workflow therefore favors availability and operational resilience over instantaneous cross-service atomicity.

Learning points. The correct protocol follows the invariant and resource boundaries. Durable workflow state, idempotency, observability, and explicit compensation are as important as the happy-path sequence.

10. Governance, Security, and Contemporary Practice

Transaction identifiers, logs, and messages may contain financial or personal data. Access to transaction logs and administrative resolution tools should be restricted, audited, encrypted in transit and at rest, and retained according to legal requirements. A system should minimize sensitive data in diagnostic traces and define deletion or redaction policies without destroying records required for regulatory audit.

Cloud-native architectures increasingly use workflow engines, transactional messaging, CDC pipelines, and event-driven sagas rather than a single global transaction domain. AI may assist anomaly detection—for example, identifying unusually old prepared transactions or compensation loops—but it should not autonomously force commit or abort without deterministic policy, authorization, and auditability. Machine-learning predictions do not replace the safety properties of a commit protocol.

Best practices include keeping distributed transactions short, limiting participant count, avoiding remote calls while holding locks, using durable and replicated coordinator state, making handlers idempotent, testing crash points systematically, and documenting invariants. Chaos tests should inject process crashes, delayed messages, duplicate messages, lost acknowledgements, and partitions. Correctness must be evaluated separately from availability and performance.

Chapter Summary

Distributed transactions coordinate work across independent resource managers. ACID properties remain the target, but atomicity and isolation become difficult because failures and communication delays are distributed. A transaction manager creates and tracks global work; a coordinator executes the commit protocol; participants prepare, log, and apply the final decision.

Two-phase commit obtains votes and then broadcasts one durable decision. Its central limitation is blocking while participants are prepared but uncertain. Three-phase commit adds a pre-commit state and can reduce blocking only under stronger timing and failure assumptions. Presumed commit reduces logging or acknowledgement overhead when commit is the expected outcome; it does not weaken the atomicity requirement.

Sagas replace one global atomic action with a sequence of local transactions and compensations. They suit long-running, loosely coupled workflows but require explicit business reversal, idempotency, durable state, retries, reconciliation, and acceptance of temporary inconsistency. Protocol choice must be based on invariants, resource ownership, failure assumptions, and business tolerance for compensation.

Key Terms

Global transaction: A logical transaction spanning multiple resource managers.

Atomic commitment: Agreement by all required participants on commit or abort.

Transaction manager: Component that creates, tracks, and controls transaction execution.

Coordinator: Protocol role that collects votes and distributes the global decision.

Participant: Resource manager involved in a transaction branch.

Resource manager: Component that owns data and executes local transactional work.

Prepare: State in which a participant has durably recorded readiness to commit.

Two-phase commit: Atomic-commit protocol consisting of prepare/vote and decision phases.

Three-phase commit: Protocol adding a pre-commit phase between voting and final decision.

Blocking: Inability of a prepared participant to decide while the coordinator is unavailable.

Presumed commit: Optimization treating commit as the default logging outcome.

Presumed abort: Optimization treating abort as the default logging outcome.

Saga: Sequence of local transactions coordinated through forward and compensating actions.

Compensation: Business operation intended to counteract a completed forward action.

Orchestration: Saga style directed by a central workflow coordinator.

Choreography: Saga style in which services react to published events.

Idempotency: Property that repeating an operation has the same intended effect as performing it once.

Outbox pattern: Atomic recording of a local change and its pending outgoing event.

In-doubt transaction: Transaction whose participant cannot yet determine the global decision.

Review Questions

Short Answer Questions

1. What distinguishes atomic commitment from serializability?
2. Why must a participant retain resources after voting YES in 2PC?
3. What is the blocking problem in two-phase commit?
4. How does presumed commit reduce protocol overhead?
5. Why is compensation not identical to erasing a transaction’s history?

Long Answer Questions

1. Explain the architecture and complete failure behavior of a two-phase commit system.
2. Compare 2PC and 3PC, including their assumptions and limitations.
3. Discuss how durable logs support recovery of coordinators and participants.
4. Explain orchestration and choreography in saga systems and evaluate their trade-offs.
5. Develop criteria for selecting 2PC, 3PC, or a saga for an enterprise workflow.

Analytical / Application Questions

1. A coordinator crashes after all participants vote YES but before the decision is delivered. Analyze the safe actions of participants and the recovery information required.
2. Design a saga for hotel booking involving room reservation, payment, and notification. Identify forward actions, compensations, idempotency keys, and irrecoverable cases.
3. An organization proposes using an AI model to force resolution of old in-doubt transactions. Critically evaluate the proposal from correctness, governance, security, and audit perspectives.

Multiple Choice Questions with Answers

Question 1

Which condition permits a two-phase commit coordinator to decide COMMIT?

A. At least one participant votes YES

B. Every required participant votes YES

C. The coordinator times out

D. The fastest participant commits locally

Correct Answer: B. Every required participant votes YES

Question 2

Why can a prepared participant block in two-phase commit?

A. It has no transaction identifier

B. It has already released all recovery information

C. It cannot safely choose commit or abort without the global decision

D. It must always wait for a client query

Correct Answer: C. It cannot safely choose commit or abort without the global decision

Question 3

What is the principal additional phase in three-phase commit?

A. Authenticate

B. Pre-commit

C. Compensate

D. Replicate

Correct Answer: B. Pre-commit

Question 4

Presumed commit is best described as:

A. A replacement for durable logging

B. A guarantee that every transaction commits

C. A logging and message optimization that assumes commit is common

D. A saga compensation strategy

Correct Answer: C. A logging and message optimization that assumes commit is common

Question 5

Which statement about a participant that voted YES is correct?

A. It may unilaterally abort after any timeout

B. It must be able to commit after learning the decision

C. It may discard its prepare record immediately

D. It becomes the new coordinator automatically

Correct Answer: B. It must be able to commit after learning the decision

Question 6

In a saga, a compensation is:

A. A network retransmission

B. A local lock

C. A business action intended to counteract a completed action

D. A second voting phase

Correct Answer: C. A business action intended to counteract a completed action

Question 7

Which pattern atomically records a local database change and an outgoing event?

A. Outbox pattern

B. Round-robin locking

C. Presumed abort

D. Three-way handshake

Correct Answer: A. Outbox pattern

Question 8

Which workflow is generally the strongest candidate for a saga?

A. A short transfer between databases supporting one transaction manager

B. A long-running order process spanning independent services with defined compensations

C. A single-row local update

D. A read-only query

Correct Answer: B. A long-running order process spanning independent services with defined compensations

Question 9

What does a network timeout prove in standard 2PC?

A. That the transaction must abort

B. That the transaction must commit

C. Neither commit nor abort safely, without further protocol information

D. That all participants have crashed

Correct Answer: C. Neither commit nor abort safely, without further protocol information

Question 10

Which is a major operational requirement for saga command handlers?

A. Non-repeatability

B. Idempotency

C. Permanent lock retention

D. Ignoring duplicate events

Correct Answer: B. Idempotency