Distributed Systems
Commit Protocols
3Phase Commit
Systems Architecture
Database Management

3Phase commit protocol - Distributed System

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

The 3Phase Commit Protocol (3PC) is an enhancement of the popular two-phase commit protocol (2PC) used in distributed systems to achieve consensus or agreement on a single action, usually related to database transactions or updates. These protocols are crucial in ensuring that all participants in a distributed system agree on a particular action or transaction, thereby maintaining consistency across the system.

Overview of the 3Phase Commit Protocol

Unlike 2PC, which can leave systems in an uncertain state if a coordinator fails mid-transaction, 3PC is designed to be a non-blocking protocol, which means it can make progress even if there are failures under certain conditions. This is achieved through an additional phase between the 'prepare to commit' and 'commit' phases of 2PC.

Phases of 3PC

  1. Pre-Commit: This phase is an extension where participants prepare to commit but do not actually commit yet.
  2. Commit Intention (Ready to Commit): In this state, all nodes indicate they are ready to make the change and will move to commit unless a failure occurs. This phase ensures that if the coordinator fails, other nodes can decide whether to proceed or abort based on the received information.
  3. Commit or Abort: Finally, the participants either commit the transaction if all goes well or abort if any issues are detected.

Process Workflow with Examples:

Phase 1: Prepare to Commit

  • Coordinator Action: The coordinator sends a 'prepare' request to all participants.
  • Participants Action: Each participant checks if it can commit the transaction. If possible, it responds 'Yes', otherwise it sends 'No'.

Example scenario: A system updating account balances across different banks would require all relevant nodes (or data centers of each bank) to 'prepare' the relevant records for updating.

Phase 2: Pre-Commit

  • Coordinator Action: If all participants agree (all 'Yes'), the coordinator sends a 'pre-commit' message.
  • Participants Action: Participants acknowledge the reception of the 'pre-commit' and prepare to transition to the 'commit' phase but still can abort at this stage if instructed.

Phase 3: Commit/Abort

  • Coordinator Action: If all acknowledgements are received in the pre-commit stage, the coordinator sends a 'commit' order.
  • Participants Action: Commit the transaction and reply with an 'acknowledgement' or, if any fail during the previous stages, send an 'abort' command.

The elements of fault tolerance and handling failure distinguish 3PC from 2PC greatly, as it effectively handles the scenario where a coordinator may fail after sending pre-commit instructions.

Fault Tolerance

3PC introduces the ability to handle different types of failures. For example, if a coordinator fails before sending the pre-commit command, participants will time-out and abort the transaction. Alternatively, if the failure occurs post the pre-commit command but before the commit command, participants will still proceed with the commit after a time-out period.

Comparison Table: Two-Phase vs. Three-Phase Commit Protocol

FeatureTwo-Phase CommitThree-Phase Commit
Number of Phases23
BlockingYesNo
Fault ToleranceLowHigh
Recovery from Coordinator FailHardEasier
ComplexityLowerHigher
DurationShorterLonger

Use Cases and Applications

3PC is particularly beneficial in systems where the cost of blocking is high and the reliability requirements are stringent. Examples include distributed databases, financial transaction systems, and other systems requiring a high degree of consistency and minimal downtime.

Conclusion

Though three-phase commit offers a robust solution for distributed transaction management, its complexity and increased message overhead mean it is not suitable for all systems. Its use is best considered in contexts where the benefits of non-blocking operations and the handling of coordinator failures during transactions justify the additional overhead.


Course illustration
Course illustration

All Rights Reserved.