Distributed database transactions

in A distributed database environment, a database transaction can update data on multiple sites, a database transaction called a distributed transaction.

Distributed transactions must satisfy the characteristics of traditional transactions, that is, atomicity, consistency, separation and persistence. However, during distributed transactions, some sites (servers) may fail, or some sites cannot be accessed due to network failure. In order to prevent the partial failure of the distributed system, the inconsistency of data is generated. A two-phase commit protocol (two-phase commit Protocol) is used in the control of distributed transactions. The commit of a transaction is divided into two phases: Pre-submission phase (Pre-commit Phase) Post-decision stage (Post-decision Phase) 　　Two-phase commits are used to coordinate the activities of multiple servers participating in an update to prevent the inconsistency of the data when a partial failure of the distributed system occurs. For example, if an update operation requires that a record at three different nodes be changed, and if one node fails, the other two nodes must detect the failure and cancel the changes they have made. To support two-phase commits, the servers involved in a distributed update transaction must be able to communicate with each other. In general, a server is designated as a "control" or "commit" server and monitors information from other servers. During a distributed update, each server first flags the part of the distributed transaction that they have completed (but not committed) assigned to them, and is ready to commit (so that their updated parts become permanent). This is the first phase of a two-phase commit. If one node fails to respond, the control server instructs the other nodes to undo the effects of the various parts of the distributed transaction. If all nodes are answered ready for submission, the control server instructs them to commit and wait for their response. The wait for confirmation phase is the second stage. After receiving the instructions that can be submitted, each server submits its own portion of the distributed transaction and sends back the submission completion information to the control server. In a distributed transaction, there must be a site server as the Coordinator (Coordinator), which can make requests to servers in other venues and respond to their responses, which control the submission or revocation of a distributed transaction. The server for other sites involved in the distributed transaction is called a contributor (Participant). The process for transaction two phase commit is as follows: Two-phase commits are initiated when the application issues a commit command to the coordinator. The submission enters the first stage, i.e. the pre-submission phase. In this phase: (1) The facilitator prepares a local (that is, locally) to submit and write a "pre-commit" log entry in the log, and contains the names of all participants with the transaction. (2) The facilitator asks the participant if the transaction can be submitted. A participant may not be able to submit for several reasons. For example, the server provides a constraint (Constraints) when the delay check does not meet the constraints, cannot be committed, the participant's own server process or hardware fails, cannot be committed, or the coordinator does not access a participant (network failure), when the coordinator is considered to have received a A negative answer. (3) If the participant is able to submit, write a "ready to submit" log entry in its own log, which is immediately written to the hard disk and then sent back to the coordinator for a quot; ready to submit "answer. (4) The coordinator waits for all participants to answer, and if a participant sends back a negative answer, the coordinator revokes the transaction and sends a "undo" message to all participants, ending the distributed transaction and undoing all the effects of the transaction. If all participants return a message that is ready to commit, the commit of the transaction goes to the second stage, the post-decision submission phase. In this phase: (1) The coordinator writes the "commit" log entry in the log and writes it to the hard disk immediately. (2) The facilitator issues a "submit this transaction" order to the participant. After each participant receives the command, it writes the "commit" log entry in its own log and writes it to the hard disk immediately. It then sends back the "committed" message, releasing the resource that the transaction occupies. (3) When all participants return the "committed" message, the coordinator writes the "transaction commit complete" log entry in the log to release the resource that the coordinator occupies. This completes the commit of the distributed transaction.

Distributed database transactions