Transaction and two-phase commit

Transaction and two-phase commit

• 1. Acid of the transaction

Transactions are fundamental to ensuring that databases change from a consistent state to another consistent state permanently. acid is the basic feature of transactions.

A Is atomicity and atomic. A transaction often involves many sub-operations. atomicity ensures that these sub-operations are either done or not done, so that some operations of the transaction are not successful, and other operations are not successful. If an error occurs during the transaction execution, the database rolls back to the state before the transaction occurs. For example, in the Bank's transfer service, the final result of this transaction must be: the balance of one account is increased by X, while the balance of another account is reduced by X, or the balance of the two accounts has not changed. But there will be no other situations.

C is consistency, consistent. Consistency means that the constraints of the database are not damaged before and after a transaction occurs, ensuring the correctness, validity, and integrity of the database elements. This constraint relationship can be an internal constraint of the database. For example, the value of the database element must be within a certain range, or it can be a constraint of the application, for example, the balance of the bank account cannot be negative after the transfer.

I is isolation, isolation. Before a transaction is committed, it will not be accessed by other transactions in parallel. That is to say, the database operation will not see the intermediate operation result of a transaction. For example, during the transfer process, the user cannot find that the balance of one account has been reduced, but the balance of another account has not changed.

D is durability and persistent. After a transaction is completed, its impact on the database is permanent, and the impact will be maintained even when the database system goes down or fails.

• 2. Two-Phase submission

In a distributed system, transactions often contain activities of multiple participants. Activities on a single participant can guarantee atomicity, the guarantee of atomicity between multiple participants is achieved through two-phase commit, which is the key to implementing distributed transactions.

Obviously, the two-phase commit ensures the atomicity of distributed transactions. These Sub-transactions are either done or not done. Database Consistency is implemented by the integrity constraints of the database, and durability is achieved through the commit log, not guaranteed by Two-phase commit. For how to ensure isolation of two-phase commit, refer to the specific implementation of two-phase commit in large-scale incremental processing using distributed transactions and notifications.

The two-phase submission process involves the coordinator and participants. The Coordinator can be seen as the initiator of the transaction and also a participant in the transaction. For a distributed transaction, a transaction involves multiple participants. The specific two-phase submission process is as follows:

Stage 1:

First, the Coordinator writes a log record in the log of its node, and then all the participants send the message prepare T, asking these participants (including themselves) whether they can submit the transaction;

After a participant receives the prepare t message, it pre-processes the transaction based on its own situation. If the participant can submit the transaction, the log is written to the disk, then, a ready t information is returned to the Coordinator and enters the pre-commit state. If the transaction cannot be submitted, logs are recorded and a not commit T information is returned to the Coordinator, at the same time, the database changes made on itself are revoked;

The participant can postpone the response sending time, but it still needs to be sent.

Stage 2:

The Coordinator collects comments from all participants. If the not commit t message is received from the participant, it indicates that the transaction cannot be committed and the Coordinator will record the abort T to the log, send an abort t message to all participants so that all participants can cancel all their pre-operations;

If the Coordinator receives a prepare t message from all participants, the Coordinator writes the commit T log to the disk and sends a commit t message to all participants to submit the transaction. If the Coordinator has not received a message from a participant, the participant is deemed to have sent a vote_abort message to cancel the execution of the transaction.

After the participant receives the abort T information sent by the Coordinator, the participant terminates the submission and records the abort T in the log. If the participant receives the commit T information, the transaction is committed and written into the record.

Generally, the two-phase commit mechanism can run well. When a participant goes down during a transaction, after he restarts, he can ask other participants or coordinators, to know whether the transaction has been committed. Of course, the premise is that each participant writes logs in advance during each step of operation.

The only dilemma that cannot be solved by Two-phase commit is that when the Coordinator sends the commit t message, the only participant who receives the command goes down, at this time, the transaction is in an unknown state. No one knows whether the transaction has been committed or not. This requires the intervention of the database administrator to prevent the database from entering an inconsistent state. Of course, if one premise is that all node or network exceptions will eventually be restored, the problem will not exist, and the coordinators and participants will eventually restart, other nodes will eventually receive the commit T information.

• 3 logs

Database logs ensure the atomicity and durability of transaction execution. log types include redo log, UNDO log, and undo/redo log. For details about these log forms, refer:

Http://nosql-wiki.org/foswiki/bin/view/Main/TransactonLog