Two-Phase Commit (2PC)

2PC is a synchronous and blocking protocol, which directly impacts system latency and throughput.

• Multiple Round Trips: The protocol requires at least two rounds of network communication (prepare → vote → decision → ack), increasing transaction latency.
• Held Locks: From the prepare phase until the final decision, participants must hold any locks on affected resources. This increases lock contention and reduces concurrency, as other transactions are blocked from accessing the same data.
• Not Partition Tolerant: Under the CAP theorem, 2PC prioritizes Consistency and Atomicity but sacrifices Availability during network partitions. If the coordinator is partitioned from a participant, the entire transaction may block indefinitely.

A key application of 2PC is in coordinating transactions across heterogeneous resources, such as different database vendors or message queues. This is standardized via the X/Open XA (eXtended Architecture) standard.

• XA defines interfaces between a global Transaction Manager (the coordinator) and local Resource Managers (the participants).
• It allows a single transaction to span operations in, for example, an Oracle database and an IBM MQ queue, ensuring atomic commit across both.
• The Java Transaction API (JTA) is a common Java implementation of this pattern. While powerful for integration, XA transactions inherit all 2PC's complexities regarding performance and recovery.

For long-running business processes, the Saga pattern is often a more suitable alternative to 2PC. The key differences are:

• Compensating Transactions vs. Rollback: Where 2PC uses an atomic abort (rollback), a Saga uses a series of compensating transactions (application-level undo operations) to reverse the effects of completed steps if a later step fails.
• No Global Locks: Sagas do not require long-held, global locks. Each local transaction commits its changes immediately, releasing resources and improving concurrency.
• Eventual Consistency: Sagas typically offer eventual consistency between services, whereas 2PC aims for strong consistency at commit time. This makes Sagas more resilient to long network delays and partitions but requires careful design of compensation logic.

2PC is a foundational algorithm, but it lacks fault tolerance for the coordinator. More advanced consensus protocols address this:

• Three-Phase Commit (3PC): Introduces an extra pre-commit phase to eliminate the blocking problem when the coordinator fails. Participants can unanimously transition to a pre-commit state, allowing them to safely commit even if the coordinator disappears. However, 3PC is more complex and still vulnerable to network partitions.
• Paxos & Raft: These are true consensus algorithms designed for replicating a state machine across a cluster (e.g., etcd, Consul). They use leader election and quorums to tolerate node failures and are non-blocking. They solve a different problem (agreeing on a log of commands) but are architecturally more robust than 2PC for building highly available coordination services.

The Saga pattern is a failure management pattern for long-running transactions that breaks the transaction into a sequence of local transactions, each with a compensating transaction to undo its effects if a later step fails. It is an alternative to 2PC for complex, distributed business processes where holding locks for extended periods is impractical.

• Compensating Actions: Each step has a defined undo operation (e.g., CancelOrder compensates for CreateOrder).
• Event-Driven: Often choreographed via events or orchestrated by a central coordinator.
• Trade-off: Achieves eventual consistency and better availability but requires careful design of rollback logic.

Byzantine Fault Tolerance (BFT) is the property of a consensus system to reach agreement correctly even when some agents fail arbitrarily or behave maliciously, known as Byzantine failures. This is a stricter requirement than 2PC, which assumes fail-stop (non-malicious) failures.

• Adversarial Model: Protects against agents sending conflicting, incorrect, or misleading messages.
• Protocol Complexity: Requires more message rounds and participants (e.g., 3f+1 replicas to tolerate f faults) than crash-fault-tolerant protocols.
• Practical Implementation: PBFT (Practical Byzantine Fault Tolerance) is a canonical algorithm in this class.

Optimistic Concurrency Control (OCC) is a conflict resolution strategy where transactions proceed without locking, and conflicts are detected at commit time, requiring conflicting transactions to be rolled back and retried. It contrasts with 2PC's pessimistic, locking-based approach.

• Three Phases: Read, Validation, Write.
• High Throughput: Performs well in low-conflict environments by avoiding lock overhead.
• Validation Check: At commit, the system verifies that read data has not been modified by others. If a conflict is detected, the transaction aborts and may restart.

The CAP theorem is a fundamental principle in distributed systems stating that a networked shared-data system can provide only two out of three guarantees: Consistency, Availability, and Partition tolerance. 2PC is a protocol that prioritizes Consistency and Partition tolerance (CP) at the expense of Availability during a network partition.

• Consistency (C): Every read receives the most recent write.
• Availability (A): Every request receives a response.
• Partition Tolerance (P): The system continues operating despite network failures.
• 2PC's Trade-off: In a partition that isolates the coordinator, participant agents may block indefinitely, becoming unavailable until the partition heals.