In distributed systems, transactional consistency is guaranteed by the Atomic Commit Protocol. It coordinates two phases—voting and decision—to ensure that a transaction is either fully committed or completely canceled on several nodes.
Distributed Transactions
Distributed transaction refers to a transaction in which multiple servers are involved. Multiple servers are called by a client in Simple Distributed Transaction whereas a server calls another server in Nested Transaction. The execution of a transaction at many sites, must either be committed at all sites or aborted at all sites. However, this should not be the case when a transaction is committed at one site and aborted at another site. Distributed site systems use distributed commitment rules to ensure atomicity across sites. Atomic commitment is a channel of need for cooperation across a variety of systems.
Properties of the Distributed Transactions
The distributed transactions must possess the following ACID properties, like any other transaction. In distributed systems, a transaction manager is used to coordinate the distinct operations and then commit/rollback the transaction as needed.
- Atomicity: All data changes are treated as if they were a single operation. That is, either all of the modifications are made, or none of them are made. The atomicity feature assures that if a debit is successfully made from one account, the matching credit is made to the other account in an application that transfers money from one account to another.
- Consistency: This property implies that when a transaction begins and ends, the state of data is consistent. For example, it ensures that the value remains consistent at the start and end of a transaction in an application that transfers funds from one account to another.
- Isolation: In this property, concurrently running transactions appear to be serialized. For example, the isolation property assures that the transferred funds between two accounts can be seen by another transaction in either one of the accounts, but not both, or neither.
- Durability: Changes to data persist when a transaction completes successfully and are not undone, even if the system fails. It assures that modifications made to each account will not be reversed in an application that transfers money from one account to another.
Coordination in Distributed Transactions
At the time of coordination in Distributed Transactions, one of the servers becomes a coordinator, and the rest of the workers become coordinators.
- In a simple transaction, the first server acts as the Coordinator.
- In the nested transaction, the top-level server acts as the Coordinator.
- Role of Coordinator: The coordinator keeps track of participating servers, gathers results from workers, and makes a decision to ensure transaction consistency.
- Role of Workers: Workers are aware of the coordinator’s existence and in addition, communicate their outcome to the coordinator and then follow the coordinator’s decision.
Atomic Commit
The atomic commit procedure should meet the following requirements:
- All participants who make a choice reach the same conclusion.
- If any participant decides to commit, then all other participants must have voted yes.
- If all participants vote yes and no failure occurs, then all participants decide to commit.
Distributed One-Phase Commit
A one-phase commitment protocol involves a coordinator who communicates with servers and performs each task regularly to inform them to perform or cancel actions i.e. transactions.
One phase Commit
Distributed Two-Phase Commit
There are two phases for the commit procedure to work:
Phase 1: Voting
- A “prepare message” is sent to each participating worker by the coordinator.
- The coordinator must wait until a response whether ready or not ready is received from each worker, or a timeout occurs.
- Workers must wait until the coordinator sends the “prepare” message.
- If a transaction is ready to commit then a “ready” message is sent to the coordinator.
- If a transaction is not ready to commit then a “no” message is sent to the coordinator and resulting in aborting of the transaction.
Phase 2: Completion of the voting result
- In this phase, the Coordinator will check about the “ready” message. If each worker sent a “ready” message then only a “commit” message is sent to each worker; otherwise, send an “abort” message to each worker.
- Now, wait for acknowledgment until it is received from each worker.
- In this phase, Workers wait until the coordinator sends a “commit” or “abort” message; then act according to the message received.
- At last, Workers send an acknowledgment to the Coordinator.
Two phase Commit
Conclusion
In Conclusion, the Atomic Commit Protocol is essential to maintaining transaction dependability and consistency in distributed systems. Its main goal is to ensure that, even in the event of a failure, a transaction is either fully committed or fully aborted across all participating nodes.