2PC: Two-phase commit protocol

In a distributed system, transactions involve altering data on multiple databases, Which causes the processing to be more complicated since the database has to coordinate with the other operable units for committing or rolling back of changes in a transaction as a self-contained unit. Either the entire transaction commits or the entire transaction rolls back. When the data is spread across different DC’s in distributed computing, each server is an independent entity with separate log records, the process can become more complex.

• The two-phase commit protocol (2PC) has been used in different enterprise software for a couple of years.
• Oracle, IBM DB2, PostgreSQL, MariaDB, VoltDB, Cloud Spanner, Apache Flink, Apache Kafka, and Azure SQL Database uses this.
• If your system supports ACID transactions across shards/partitions/databases, there’s a high probability that it is running 2PC.

How does 2PC commit works?

This protocol has two phases that is why it is called as Two-phase commit protocol.

• The first phase is called as PREPARE
• The second phase is called as COMMIT.

Two units were used Co-ordinator and Participator(or worker).

• Co-ordinator: who initiate the transactions
• Participator: which participates in these transactions.

Not clear don’t worry you will understand in upcoming descriptions

Explanation:

Phase1: The co-ordinator asks from each participator whether they have successfully completed their responsibilities for that transaction and are ready to commit. Each participator responds ‘yes |OK’ or ‘no|abort’.

• Every participator writes its data records in a log. If it is unsuccessful to do, then it responds with a failure message; if it is successful, then it sends an OK message.

Phase2: This phase will start when Co-ordinator receive successful response in phase 1 from all participator.

• Now Co-ordinator sends a commit request to all the participators.
• Now participators write the commit as part of its log record.
• Participants send a message that its commit has been successfully implemented.
• If a server fails, the coordinator sends instructions to all servers to roll back the transaction

This mechanism ensures the ACID transactions guarantee

Atomicity: either the entire transaction will be reflected in the final state of the system or none of it.

Consistency: Either Transaction is successful or its rollback.

Isolation: Concurrent transactions do not interfere with each other

Durability: After successful completion of a transaction all changes made by the transaction persist even in the case of a system failure.

Thanks

Happy Learning!!