Two-Phase Commit (2PC)

A major drawback of 2PC is its blocking nature. After voting YES in Phase 1, a participant enters a prepared state and is blocked, holding resources (like locks) until it receives the coordinator's final decision.

If the coordinator fails after cohorts vote YES but before sending the decision, cohorts are blocked indefinitely. They cannot unilaterally decide to commit or abort without risking inconsistency. Systems implement timeout mechanisms to detect coordinator failure, but resolving a blocked transaction requires complex recovery protocols and can lead to reduced availability.

In multi-agent systems, 2PC can coordinate state changes across agents that manage different pieces of a shared memory or knowledge graph. For example, when an agentic workflow requires updating multiple, independent vector databases or CRDT states as a single logical operation, 2PC ensures all updates are applied atomically.

However, its synchronous and blocking nature is often at odds with the asynchronous, fault-tolerant design goals of modern agent systems, leading to the use of alternative patterns like Saga or eventual consistency models for long-running transactions.

It's crucial to distinguish 2PC from consensus protocols like Paxos or Raft:

• 2PC (Atomic Commitment): Assumes all nodes are working correctly during execution. Its goal is to get unanimous agreement on the outcome of a pre-determined transaction. It is not designed to tolerate Byzantine faults.
• Paxos/Raft (State Machine Replication): These protocols are used to agree on a sequence of commands (a log) across replicas, even in the face of node failures. They elect a leader and replicate logs to achieve strong consistency.

2PC is often used on top of a replicated log system; Raft can be used to replicate the coordinator's decision log to make it fault-tolerant.

For correctness after failures, both the coordinator and participants must write persistent log records at critical points:

• Coordinator Logs: prepare sent, global-commit or global-abort decision.
• Participant Logs: prepare received, vote (yes/no), final decision received.

On recovery after a crash, a node reads its log to determine its pre-crash state. A participant that logged yes but no final decision must query the coordinator or other participants to discover the outcome. This write-ahead logging is essential but contributes to the protocol's latency.

An extension of 2PC designed to reduce blocking in the face of coordinator failure. It introduces an additional pre-commit phase between the vote and the final commit/abort. This phase ensures that all participants know others are ready to commit before the point of no return. If the coordinator fails after pre-commit, participants can safely commit independently, avoiding the indefinite blocking possible in 2PC.

• Key Improvement: Non-blocking under certain failure scenarios.
• Trade-off: Increased message complexity and latency due to the extra round of communication.
• Use Case: Systems where coordinator availability is a critical concern.

A failure management pattern for long-running transactions that breaks a business process into a sequence of local transactions. Each local transaction updates the database and publishes an event or message to trigger the next step. If a step fails, compensating transactions are executed to undo the effects of the preceding steps. This contrasts with 2PC's all-or-nothing atomicity, favoring eventual consistency and better scalability.

• Architecture Style: Choreography (events) or Orchestration (central coordinator).
• Advantage over 2PC: Avoids long-lived locks on resources, improving scalability.
• Disadvantage: Application logic must define and implement rollback compensations.

A data structure designed for coordination-free concurrent updates in distributed systems. CRDTs are mathematically guaranteed to converge to the same state across all replicas, regardless of the order of operations, as long as all updates are eventually delivered. This provides a strong alternative to 2PC for data where immediate strong consistency can be relaxed in favor of availability and partition tolerance.

• Core Property: Commutative, associative, and idempotent operations.
• Consistency Model: Provides Strong Eventual Consistency.
• Contrast with 2PC: Eliminates the need for a prepare/commit protocol, enabling always-writable replicas.

A service that provides mutually exclusive access to resources (e.g., a memory segment, a file, a data record) across nodes in a distributed system. DLMs are often a lower-level primitive used to implement isolation guarantees for transactions coordinated by protocols like 2PC. They manage lock acquisition, renewal, and release, often using leases to prevent deadlock from failed nodes.

• Primary Function: Serialize access to shared resources.
• Implementation: Can use consensus protocols (like Raft) for fault tolerance.
• Relation to 2PC: A 2PC participant may acquire a DLM lock on a resource during the transaction's execution phase.