Two-Phase Commit, Isolation and Rethinking the Boundaries

Objectives

By the end of the lesson, you can explain how the two-phase commit works and what its limits are, distinguish atomicity from isolation, and judge when it is worth rethinking the service boundary.

Why is it needed?

When the shared transaction is missing, two questions arise: can an atomic commit still be requested from several participants, and what happens to the intermediate state that the saga exposes to other operations. The first is the two-phase commit, the second is the question of business-level isolation.

Two-phase commit

The two-phase commit (2PC) uses a coordinator to agree on the participants' joint commit. In the first phase the coordinator asks the participants whether they are ready to commit; they do the work up to the commit point, log it, and vote yes or no. In the second, if everyone said yes, the coordinator commits; otherwise it rolls back.

sequenceDiagram
  participant K as Coordinator
  participant A as Participant A
  participant B as Participant B
  K->>A: Prepare
  K->>B: Prepare
  A-->>K: Ready
  B-->>K: Ready
  K->>A: Commit
  K->>B: Commit

According to Wikipedia the greatest disadvantage of 2PC is that it is a blocking protocol: a participant that voted yes must wait for the coordinator's decision, and if the coordinator fails permanently, it may wait indefinitely. The locks remain during the wait.

The PostgreSQL documentation describes the PREPARE TRANSACTION command as a tool created for an external transaction manager and explicitly not meant for applications; a transaction left in the prepared state for a long time holds locks, hinders cleanup, and in extreme cases may even cause the database to shut down. This shows well that 2PC can only be used with participants that support the protocol: an arbitrary HTTP endpoint does not become a 2PC participant.

In return for the joint commit, a stronger runtime and infrastructure dependence appears.

Saga and isolation

With a saga, the local transactions have already been executed when the next step starts, so other operations may see the intermediate state. Atomicity and isolation are two separate questions: even if a faulty flow is eventually compensated, other operations may already have seen the intermediate state.

For the intermediate state an explicit business-level isolation rule is needed. It can be a temporary reservation with an expiry, a state-bound permission to act, or version checking. According to microservices.io the lack of isolation in sagas must be handled with countermeasures. These are not the same as the isolation of a shared database transaction.

Two parallel sagas may compete for the same resource; the owner of the resource must make an atomic decision locally. A late compensation must not touch another operation blindly either: the identifier of the concrete reservation and a state check protect against an old compensation spoiling a new state.

Comparison

Aspect	Local transaction	2PC	Saga
Scope	One database	Several participants supporting the protocol	Several services
Atomicity	Yes	Yes (within the protocol)	No; compensation
Isolation	Yes	Yes	None; to be replaced by business rules
Availability	Depends on one database	Coordinator and participants together; blocking possible	No blocking, but intermediate states
Complexity	Low	Infrastructure	Application logic

Rethinking the boundary

If two pieces of data need an immediate, shared invariant in every operation, it is worth examining whether they really need to belong to separate data owners. A bad split is not fixed by more infrastructure: a modular monolith or a larger, cohesive service may be simpler and more correct (2.4, 3.2). The reason for a separate service may also be a regulatory or organisational requirement; in that case the process state and reconciliation must be taken on, and it must be stated exactly what is guaranteed.

Common misconceptions

Statement	Clarification
"2PC can be used with any service."	Only with participants supporting the protocol.
"2PC is guaranteed to keep working."	It is a blocking protocol; a coordinator failure can mean waiting.
"A saga is isolated like a transaction."	There is no isolation; it must be replaced by business rules.
"A bad split is solved by more infrastructure."	Sometimes merging the boundary is the right answer.

In short

• 2PC gives a joint commit to participants supporting the protocol, but it is blocking.
• A saga gives up isolation; it must be replaced by business rules (expiring reservation, state check, version).
• Atomicity and isolation are separate questions.
• If two pieces of data require a shared, immediate invariant, the boundary should be rethought.

Review questions

1. Why is 2PC a blocking protocol?
2. How does an expiring reservation protect the system from the intermediate state?
3. When is it worth merging two services into one data owner?

Learning resources

• Two-phase commit protocol (Wikipedia) — the two phases, the drawback of blocking.
• PREPARE TRANSACTION (PostgreSQL) — operation and warnings of a concrete prepared transaction.
• Saga pattern (microservices.io) — the lack of isolation and countermeasures.