Distributed Transactions and 2 Phase commit protocol
To start with let us a have a very very simple definition for a distributed system. A distributed system would be one where the systems's resources are located in different locations (for large distributed systems different applies at geographical scales. For. E.g amazon has its data centers, web servers are spawned across multiple geographic locations.)
Let us also define in simple terms a transaction. Transaction is a set of operations on a recoverable data item ( i.e. data item that can be taken back to its previous state should the operations fail. Typical example of recoverable data item is database records)
Distributed transaction is a transaction we intend to perform on a distributed system. Given the nature of the system the operations in the transaction might have to be executed on the resources spawned at different locations. The basic requirement of any transaction is ACID (Atomicity, Consistency, Isolation, Durability) and these same apply to distributed transactions as well.
To achieve atomic commit in a distributed transaction scenario, one of the popular protocol is the 2-phase commit protocol.
Assumptions of the 2 Phase commit protocol:
* A master/coordinator host is selected which coordinates the transaction
* All other nodes are called cohorts/participants
* Each of these nodes have stable storage and can perform write ahead logging of the operations
The 2 phase commit is named so as it has 2 phases called voting phase, commit phase. We will see how the protocol works.
Cons:
If the master fails, some of the cohorts can not complete their transactions and get blocked on the master to send commit/rollback message.
To start with let us a have a very very simple definition for a distributed system. A distributed system would be one where the systems's resources are located in different locations (for large distributed systems different applies at geographical scales. For. E.g amazon has its data centers, web servers are spawned across multiple geographic locations.)
Let us also define in simple terms a transaction. Transaction is a set of operations on a recoverable data item ( i.e. data item that can be taken back to its previous state should the operations fail. Typical example of recoverable data item is database records)
Distributed transaction is a transaction we intend to perform on a distributed system. Given the nature of the system the operations in the transaction might have to be executed on the resources spawned at different locations. The basic requirement of any transaction is ACID (Atomicity, Consistency, Isolation, Durability) and these same apply to distributed transactions as well.
To achieve atomic commit in a distributed transaction scenario, one of the popular protocol is the 2-phase commit protocol.
Assumptions of the 2 Phase commit protocol:
* A master/coordinator host is selected which coordinates the transaction
* All other nodes are called cohorts/participants
* Each of these nodes have stable storage and can perform write ahead logging of the operations
The 2 phase commit is named so as it has 2 phases called voting phase, commit phase. We will see how the protocol works.
1) The master coordinates the transaction by invoking the operations in the transaction on the appropriate cohort
2) Once the final operation of the transaction is executed, the master starts the voting phase
Voting phase:
3) Master sends a query to commit message to all cohorts
4) Upon receipt of the message each cohort completes their set of operations and write the details(undo and redo information in their logs)
5) Each cohort replies back saying Yes(for commit) or No(for rollback) based on its situation.
Commit phase:
* If master gets yes from all cohorts, he sends a commit message
* Each cohorts commits his side of changes, releases locks on resources and write commit info to log
* Sends Ack to master who then releases the resources and writes commit info to log
Rollback phase:
* If master gets at least one No from any cohort, he sends a rollback message
* Each cohorts rollback his side of changes using undo log, releases locks on resources
* Sends Ack to master who then undoes his side of things and releases the resources
If the master fails, some of the cohorts can not complete their transactions and get blocked on the master to send commit/rollback message.
this blog is not getting more updates after 2015
ReplyDelete