Two-Phase Commit (2PC)

The Distributed Transaction Problem

Imagine you are booking a dream vacation. You need to book a flight and a hotel. You have a strict rule: you only want to go if you get both. If the hotel is booked up, you want to cancel the flight. If the flight is full, you don't want the hotel.

In database terms, this is a Transaction. It must be atomic: either everything succeeds, or nothing happens.

On a single database, this is easy. You wrap the SQL statements in a BEGIN TRANSACTION and COMMIT. But what if the flight data lives in a PostgreSQL database on Server A, and the hotel data lives in a MySQL database on Server B?

This is where the Two-Phase Commit (2PC) protocol comes in. It ensures atomic transactions across distributed, disparate systems.

The Core Concept

To make 2PC work, you introduce a new component called a Coordinator. The databases (Server A and Server B) are called Cohorts (or participants).

As the name suggests, the algorithm has two phases.

Phase 1: The Prepare Phase (The "Are you ready?" phase)

Think of a wedding ceremony. The priest (Coordinator) asks both the bride and groom if they are ready to commit.

1. The Coordinator sends a "Prepare" message to Server A (Flight) and Server B (Hotel).
2. Server A checks if it can fulfill the request (Is the seat available? Do I have disk space?). If yes, it locks the seat and replies "Yes." It is now legally bound to hold that seat.
3. Server B checks the hotel room. If it's available, it locks the room and replies "Yes."

If any server replies "No" (or times out), the Coordinator immediately moves to an abort phase and tells everyone to cancel.

Phase 2: The Commit Phase (The "I pronounce you..." phase)

If the Coordinator receives a "Yes" from everyone, the transaction is a go.

1. The Coordinator writes "Commit" to its own log (so if it crashes, it remembers the decision).
2. The Coordinator sends a "Commit" message to Server A and Server B.
3. The servers finalize the database writes, release their locks, and reply "Done."

The Fatal Flaw of 2PC

2PC is great in theory, but it has a massive vulnerability: It is a blocking protocol.

Imagine this scenario:

1. Server A and Server B both reply "Yes" in Phase 1. They have now locked their rows. No one else can book that flight or hotel.
2. The Coordinator receives the Yes votes, but before it can send out the Phase 2 "Commit" message, the Coordinator crashes.

What happens to Server A and Server B? They are stuck. They promised to hold those locks until the Coordinator tells them what to do. They can't commit (because maybe someone else voted no), and they can't abort (because they promised they were ready). They just sit there, holding locks, freezing up your database tables until the Coordinator is rebooted.

Because of this single point of failure and heavy locking, 2PC is notoriously slow and fragile in large-scale distributed systems.

Real-World Examples

• Traditional RDBMS: Relational databases like PostgreSQL, MySQL (via XA transactions), and Oracle use 2PC for distributed transactions across database nodes.
• Java EE: Enterprise Java systems heavily utilized 2PC through the Java Transaction API (JTA) to coordinate transactions between message queues and databases.
• Modern Microservices: Noticeably absent. Modern large-scale architectures (like Amazon or Netflix) almost entirely avoid 2PC because it doesn't scale well, opting instead for patterns like the Saga Pattern.

Summary

• Two-Phase Commit (2PC) is an algorithm to achieve atomic transactions across distributed databases.
• It uses a Coordinator to ask participants to Prepare (Phase 1), and if everyone agrees, it tells them to Commit (Phase 2).
• It provides strong consistency but is synchronous and blocking.
• If the Coordinator crashes between phases, the system is left in an indefinite locked state, making it unsuitable for highly available microservice architectures.