Sharing a transaction boundary across resources

Independent local transactions do not ensure an all-or-nothing outcome across several nodes or databases. A distributed transaction relates participating operations to one commit-or-abort requirement.

Gray and Lamport formulate commitment as agreement among resource managers, with commitment requiring every participant’s willingness. The scope is the resources enrolled in that protocol, not arbitrary external effects automatically made reversible.

References: [1] [2]

Participants need recoverable preparation

Two-phase commit coordinates preparation and final resolution. PostgreSQL prepared transactions survive independently of the initiating session and can later be committed or rolled back by identifier under an external manager.

The manager must track unresolved preparations. PostgreSQL documents continued lock retention and maintenance effects; client disconnection or process restart must not permanently erase responsibility for resources awaiting a decision.

References: [2] [3]

Agreement is distinct from isolation and progress

A common commitment decision does not alone specify how concurrent transactions read and write. Isolation, locking, and dependency checks remain separate requirements of the participating system.

Network and coordinator failures also affect progress. Classic two-phase commit can preserve agreement while temporarily lacking a final decision. Designs need permitted outcomes, recovery responsibilities, and conditions for progress as well as the normal path.

References: [4] [1]