Two-Phase Commit (2PC)

 Two-Phase Commit (2PC)

Two-phase commit (2PC) is an algorithm for achieving Atomic transaction commit across multiple nodes.

  • 2PC is used internally in some databases and also made available to applications in the form of XA (extended architecture) transactions. XA transaction is supported by JAVA transaction API or via WSAtomicTransaction for SOAP web service. 
  • Commit/abort process in 2PC is split into two phases. 

Coordinator or Transaction Manager: 

The coordinator is often implemented as a library within the same application process that is requesting the transaction, but it can also be separate process or service. 

Phase1:  

  • When application is ready to commit, the coordinator begins phase1. 
  • It sends prepare request to each node, asking them whether they are able to commit. The coordinator then track the responses from the participants. 

Phase2: 

  • If all participants reply “yes”, indicating they are ready to commit, then coordinator sends out a commit request in phase2, and commit actually takes place. 
  • If any of the participants replies “no”, the coordinator sends an abort request to all nodes in phase2. 

Detailed steps: 

  1. When the application wants to begin a distributed transaction, it request a transaction id from the coordinator. The transaction id is globaly unique. 
  2. The application begins a single node transaction on each participants and attach the global unique transaction id to the single-node transaction.
    • All reads and writes are done in one of those single node transaction.
    • If anything goes wrong at this stage (node crash or request timeout), the coordinator or any of the participants can abort the transaction. 
  3. When the application is ready to commit, the coordinator sends a prepare request to all participants, tagged with global transaction ID. If any of this request fails or timeout, the coordinator sends an abort request for that transaction ID to all participants. 
  4. When a participant receives the prepare request, it makes sure that it can definitely commit the transaction under all circumstances.
    • This includes writing all transaction data to disk, and checking for any conflicts or constraints violation.
    • By replying “yes” to the coordinator, the node promises to commit the transaction without error if requested. 
  5. When coordinator has received response to all prepare requests, it must write decision to its transaction log on disk so that it knows which way it decided in case it subsequently crashes. This is called the commit point. 
  6. Once the coordinator decision written to disk, the commit or abort request is sent to all participants.
    • If the request fails or timeout, the coordinator must retry forever until it succeeds.
    • If a participant crashed in the meantime, the transaction will committed when it recovers. 

2PC protocol contains two crucial points of no return: 

  • When a participant votes “Yes” 
  • Commit point, when coordinator takes a decision. 

Coordinator Failure: 

  • If the coordinator fails before sending the prepare requests, a participants can safely abort the transaction. 
  • But once the participant has received a prepare request and voted “Yes”, if the coordinator crashes or the network fails at this point, the participants can do nothing but wait. 
  • A participant’s transaction at this state is called in doubt or uncertain. 
  • Without hearing from the coordinator, the participant has no way of knowing whether to commit or abort.
    • There is a possibility that network failure happened between this participant(P1) and coordinator only. While rest of the participants has good network connection with coordinator and they receive commit/Abort message from coordinator. 
  • In principle, P1 can communicate with other participants and find out decision and come to some agreement but that is not part of 2PC phase. 
  • Once coordinator recovers, it checks transaction log and take decision based on log entry. If there is no commit record in the log, then abort the transaction. 

Limitations:

  • If the coordinator is not replicated but runs only on single machine, it is a single point of failure for the entire system.
  • many server-side applications are developed in a stateless model, with all persistent state stored in a database, which has the advantage that application servers can be added or removed at will.
    • However, since coordinator logs are required in-order to recover in-doubt transactions after a crash, such application servers are no longer stateless.
  • If the part of the system is broken, then transaction also fails. Distributed transaction thus have a tendency of amplifying failures.


Comments

Post a Comment

Popular posts from this blog

Distributed Lock with Redlock

 Distributed Lock with Redlock Distributed lock systems are used to ensure that only one process or thread can access a particular resource at a time. Redlock is a distributed lock system that was introduced by Redis. The goal of Redlock is to provide a reliable and fault-tolerant distributed lock service.   The Redlock system is designed to work in a distributed environment where multiple instances of a service or application can run concurrently. Each instance of the application can acquire a lock and perform some operations on the resource. The Redlock system ensures that only one instance of the application has access to the resource at a time.   Components of Redlock :   Lock Manager : The Lock Manager is responsible for managing the lock state and deciding which instance of the application can acquire the lock. It receives requests from the applications to acquire or release the lock.   The Lock Manager uses a distributed consensus algorithm to en...
Read more

Distributed Transaction

Distributed Transaction A distributed transaction across multiple database services involves multiple databases that are geographically distributed across  different locations .       Here are some important steps to consider when designing a system for distributed transactions across multiple database services:     Transaction Protocol      Transactional consistency      Concurrency control      Reliability and Fault-tolerance      Performance   Transactional Protocol A distributed transaction protocol is a set of rules and procedures that define how a distributed transaction should be executed across multiple databases .   It is used for Atomic commit across databases    There are several distributed transaction protocols to choose from, each with its own advantages and disadvantages.     Two-Phase Commit (2PC ) :   It is a widely-used protocol that ensures at...
Read more

Storage Engine

Image
Database Storage Engine Two kinds of database storage engine are most popular: Log Structured Storage Engine (SSTable, LSMTree) Page Oriented Storage Engine (B-Tree) Log Structured Storage Engine  Most of the databases internally use a log, which is an append only data file. Log file is an append only sequence of records It is not human readable, binary file Issues Since log file is append only file, so it keeps growing, hence resulting performance issue. While reading data, every time it looks from beginning Performance degrades if number of records are more in the database To mitigate these issues, a new concept came out called Indexing. Index In order to efficiently find the value for a particular key in the database, we need a different data structure, this is called an Index. In General the idea behind them is to keep some additional metadata on the side, which acts as a signpost and helps you to locate the data you want. If you want to search some data in a several different ...
Read more