Skip to content

Latest commit

 

History

History
68 lines (39 loc) · 3.83 KB

2pc.md

File metadata and controls

68 lines (39 loc) · 3.83 KB
Raw

2PC: Two-phase commit protocol / XA Transactions

In transaction processing, databases, and computer networking, 2PC is a type of Atomic Commitment Protocol (ACP). It ensures atomicity of a distributed transaction.

It is a distributed algorithm that coordinates all the processes that participate in a distributed atomic transaction on whether to commit or abort (rollback) the transaction.

The protocol achieves its goal even in many cases of temporary system failuire, however, it is not resilient to all possible failure configurations. To accommodate recovery from failure (automatic in most cases) the protocol's participant use logging of the protocol's states. So it does not guarantee that a distributed transaction can't fail, but it does guarantee that it can't fail silently.

Many protocol variants exist that primarily differ in logging strategies and recovery mechanisms.

When is used?

  • When distributed transaction modofies more than one server including the coordinator node.
  • When the client executes postgres' PREPARE TRANSACTION or other rdbms command, 2PC is used unconditionally.

Examples

Disadvantage

The greatest disadvantage of 2PC is that is a blocking protocol. If coordinator fails permanently, some participants will never resolve their transactions. And, after a participant has sent an agreement message to the coordinator, it will block until a commit or rollback message is received.

Phases

In a "normal execution" of any single distributed transaction, the protocol consists of two phases:

  1. Commit-Request/Voting phase
  2. Commit phase

1. Commit-Request/Voting phase

A coordinator process attempts to prepare all the transaction's participating processes (workers) to take necessary steps for either committing or aborting the transaction, and to vote, either yes or no.

  • yes: commit, if the worker's local portion execution has ended properly.
  • no: abort, if a problem has been detected with the local portion.

Algorithm overview

  1. Coordinator sends a query to commit message to all participants and waits until it has received a reploy from all participants.
  2. Participants execute transaction up to the point where they will be asked to commit. They each write an entry to their undo log and an entry to their redo log.
  3. Each participant replies with an agreement message or an abort message.

2. Commit phase

Based on voting of the participants, the coordinator decides whether to commit (all have voted yes) or abort the transaction, and notifies the result to all participants.

The participants then follow with the needed actions (commit or abort) with their local transactional resources (also called recoverable resources) and their respective portions in the transaction's other output if applicable.

Success algorithm overview

If coordinator received an agreement message from all participants during the commit-request phase:

  1. Coordinator sends a commit message to all participants.
  2. Each participant completes the operation, and releasess all the locks and resources held during the transaction.
  3. Each participant sends an acknowledgement to the coordinator.
  4. Coordinator completes the transaction when all acknowledgements have been received.

Failure algorithm overview

If any participant votes abort (or coordinator's timeout expires):

  1. Coordinator sends a rollback message to all the participants.
  2. Each participant undoes the transaction using the undo log, and releases the resources and locks held during the transaction.
  3. Each participant sends an acknowledgement to the coordinator.
  4. Coordinator undoes the transaction when all acknowledgements have been received.