Two-phase commit

Two-phase commit
Name	Two-phase commit
Type	Distributed algorithm
Inventor	Jim Gray
First published	1978
Area	Transaction processing
Related	Commit protocol, Distributed systems, ACID

Two-phase commit is a distributed coordination protocol used to ensure atomic commitment across multiple database participants in a transaction. It coordinates transaction processing between a coordinator and multiple participants to provide atomicity, typically within systems implementing ACID properties and integrated with relational database management systems, message queues, and distributed transaction frameworks. Originating from work by Jim Gray and contemporaries in the 1970s, it remains a foundational mechanism in transaction processing and influenced protocols in Microsoft and Oracle product lines.

Introduction

The protocol was formalized in the context of transaction processing research at institutions like IBM and in standards such as X/Open XA for interoperable transaction processing across heterogeneous operating systems and network stacks. Two-phase commit addresses the problem of coordinating a single logical commit across multiple physical resources, such as IBM DB2, Oracle Database, Microsoft SQL Server, and PostgreSQL clusters, often orchestrated by middleware from vendors like IBM WebSphere or Red Hat JBoss. Its design reflects concerns studied in Distributed computing and by researchers associated with ACM conferences and the SIGMOD community.

Protocol Description

In phase one, the coordinator sends a prepare request to participants; participants respond with a vote to commit or abort. This interaction resembles request–response patterns used in Remote Procedure Call systems and is influenced by concepts from Lamport logical clock work and Byzantine fault tolerance discussions. In phase two, if all votes are commit, the coordinator issues a commit; otherwise it issues an abort. Implementations integrate with transaction manager components and often rely on write-ahead logging at each participant and a durable coordinator log. The protocol coordinates with network protocols such as TCP/IP and operates within environments that also use load balancers, cluster orchestration, and middleware like Apache Kafka or ActiveMQ when bridging message-oriented subsystems.

Variants and Optimizations

Optimizations include presumption-based variants (presume commit or presume abort), coordinatorless adaptations, and timeout tuning. Presumed-commit and presumed-abort reduce logging or network overhead and are employed by vendors including Oracle Corporation and Microsoft Corporation in their distributed transaction coordinator products. Coordinatorless or decentralized approaches draw on research linked to Paxos and Raft consensus algorithms and to protocols explored at Stanford University and Massachusetts Institute of Technology. Optimization techniques incorporate techniques from checkpointing research, speculative execution strategies discussed in SIGOPS proceedings, and batching approaches used in large-scale systems like Amazon Web Services and Google infrastructure research.

Failure Handling and Recovery

Failure scenarios involve coordinator crashes, participant crashes, network partitions, and durable log loss. Recovery procedures rely on stable storage, timeout and retransmission strategies, and manual or automated recovery tools as implemented in Oracle RAC, Microsoft DTC, and IBM CICS. Research into recovery draws upon work from X/Open specifications, the ACM Symposium on Operating Systems Principles, and failure models described by Leslie Lamport and Jim Gray. Handling partitions often references CAP theorem trade-offs discussed in Eric Brewer’s work and may integrate with consensus protocols like Paxos or Raft for enhanced liveness and safety. Administrative tooling from vendors such as Red Hat, VMware, and EMC Corporation provide pragmatic recovery paths in enterprise environments.

Performance and Limitations

Two-phase commit is blocking: participants may wait indefinitely if the coordinator fails, which impacts system availability in scenarios studied in CAP theorem literature and by researchers at University of California, Berkeley. The protocol incurs at least two rounds of network communication and multiple durable writes, limiting throughput under high-load conditions, leading practitioners at Google and Facebook to favor alternative strategies for large-scale services. Limitations motivated the development of non-blocking protocols and consensus-based systems like Paxos and Raft, and influenced designs in distributed databases such as Spanner and CockroachDB. Performance tuning in commercial systems leverages techniques from benchmarking research presented at TPC conferences and in white papers by Intel and AMD regarding storage and I/O optimization.

Applications and Implementations

Two-phase commit is used in banking transaction systems, enterprise resource planning suites from SAP SE, distributed commit managers in Oracle Corporation and Microsoft Corporation platforms, and transaction coordinators in Spring Framework and Java EE containers. It is embedded in message-oriented middleware like IBM MQ and Apache ActiveMQ, and in resource managers conforming to X/Open XA for interoperability across UNIX and Windows environments. Open-source implementations and discussions appear in projects hosted by Apache Software Foundation and in academic prototypes from Carnegie Mellon University and ETH Zurich.

Category:Distributed algorithms