Transaction and two phase commit, three-phase commit protocol (finite state automata)
• Acid for 1 transactions
A transaction is the fundamental to ensure that a database is permanently changed from one consistent state to another, where acid is the basic attribute of a transaction.
A is a atomicity, atomic nature. A transaction often involves a lot of child operations, and atomicity guarantees that the child operations are either done or not, without the part of the transaction being manipulated.
Successful, while the other part of the operation did not succeed. If an error occurs during the execution of a transaction, the database is rolled back to the state before the transaction occurred. Like a bank transfer service.
, the final result of this transaction must be that the balance of one account is increased by x, while the balance of the other account is reduced by x, or the balance of the two accounts has not changed. Without appearing its
His condition.
C is consistency, consistency. Consistency means that after and after a transaction occurs, it will not destroy the constraint relationship of the database, and ensure the correctness, validity and integrity of the database elements.
Of This constraint relationship can be internal to the database constraints, such as the value of the database elements must be within a certain range, or can be the application of constraints, such as the transfer of bank accounts after
The balance cannot be negative.
I is isolation, isolation. The operation of a transaction is not accessed by other transactions that occur in parallel until it is committed. In other words, the database operation does not see a transaction
Intermediate operating results, such as the transfer process, the user is not able to query the balance of one account is reduced, while the other account balance has not changed.
D is durability, persistent. After the transaction is completed, its impact on the database is permanent, even in the event of a database system outage or other failure, this effect
will be maintained.
• 22 Phase Submission
Applied in distributed systems.
In distributed systems, transactions often contain activities involving multiple actors, and the activity on a single participant is guaranteed to be atomic, and the assurance of atomicity between multiple actors requires
Two-stage commit is the key of distributed transaction implementation.
It is clear that two-phase commit guarantees the atomicity of distributed transactions, which are either done or not done. And the consistency of database is realized by the integrity constraint of database,
Persistence is achieved through a commit log, not guaranteed by a two-phase commit. As for the two-phase submission to ensure isolation, you can refer to large-scale incremental
The concrete implementation of the two-phase commit in the processing Using distributed transactions and notifications.
The two-phase commit process involves coordinators and participants. The facilitator can look at the initiator of the transaction and also as a participant in the transaction. For a distributed transaction, a
A transaction involves multiple participants. The process of specific two-phase submissions is as follows:
First stage:
First, the coordinator writes a log record in the log of its own node, and then all participants send a message prepare T asking the participants (including themselves) whether they can mention
Hand in the business;
After receiving this prepare T message, the participant will preprocess the transaction according to its own situation, and if the participant can commit the transaction, the log will be written to disk and
Returns a ready T message to the coordinator and itself into the state of the pre-commit state; If the transaction cannot be committed, the log is logged and a not commit T message is returned to the Coordinator
, at the same time undo the database changes made on their own;
Participants were able to postpone the time they sent the response, but eventually they needed to be sent.
Second Stage:
The facilitator collects the comments of all participants and, if not commit T information is received from the participant, identifies that the transaction cannot be submitted, and the coordinator logs the Abort T to the log
and sends a abort T message to all participants, allowing all participants to undo all the pre operations on their own;
If the coordinator receives prepare T information from all participants, the coordinator writes the commit T log to disk and sends a commit t message to all participants, submitting the
Transaction. If the coordinator delays receiving information from a participant, it is assumed that the participant sent a vote_abort message to cancel the execution of the transaction.
After the participant receives the abort T message from the coordinator, the participant terminates the commit and logs the abort T to the log, and if the participant receives a commit t message, it
Commit a transaction and write to a record
Under normal circumstances, two-stage commit mechanism can be better run, when in the course of the transaction, there are participants in the downtime, he restarted, you can ask other participants or coordinators
To know whether the transaction was committed or not. Of course, all this presupposes that each participant writes to the log in advance of each step.
The only time a two-phase commit cannot be resolved is when the coordinator is down after the commit T message, and the only participant who receives this command is down, and this
A transaction is in an unknown state, and no one knows whether the transaction was committed or uncommitted, requiring the intervention of the database administrator to prevent the database from entering an inconsistent
's state. Of course, if there is a prerequisite: all nodes or network anomalies will eventually be restored, then the problem does not exist, the coordinator and participants will eventually restart, the other
The node will also eventually receive a commit t message.
• 3rd Zhi
The database log guarantees the atomicity and durability of transaction execution, and the log type can be divided into redo Log,undo Log,undo/redo log. A detailed introduction to these types of log forms
, you can refer to:
Http://nosql-wiki.org/foswiki/bin/view/Main/TransactonLog
--------------------\
Two-stage commit protocol (two phase commit protocol,2pc) can ensure strong consistency of data, and many distributed relational data management systems use this protocol to complete distributed
Transaction. It is a distributed algorithm that coordinates all distributed atomic transaction participants and decides to commit or cancel (rollback). It is also a consistency algorithm to solve the consistency problem. The algorithm can
Enough to solve a lot of temporary system failures (including processes, network nodes, communications and other failures), is widely used. However, it cannot be configured to solve all faults in a
In some cases it also requires human involvement to solve the problem. Participants use logs to record the status of the protocol in order to recover from the failure, although using the log reduces performance
However, the node can recover from the failure.
In the two-phase commit protocol, the system generally contains two types of machines (or nodes): one for the Coordinator (Coordinator), and the other for the transaction participation
(Participants,cohorts or workers), typically containing multiple, can be understood in the data storage system as the number of copies of the data. The protocol assumes that each node will record the write
Pre-log (Write-ahead log) and persistent storage, even if the node fails log is not lost. The protocol also assumes that the node does not have a permanent failure and that any two sections
Points can communicate with each other.
When the last step of a transaction is completed, the coordinator executes the Protocol, and the participant agrees to commit the transaction or rollback the transaction, depending on the local transaction's successful completion of the reply.
As the name suggests, a two-phase commit agreement consists of two phases. Under normal execution, the implementation of these two phases is described as follows:
Stage 1: Request phase (Commit-request phase, or called voting phase, voting phase)
During the request phase, the coordinator notifies the transaction participant to commit or cancel the transaction and then enters the voting process. In the voting process, participants will inform the coordinator of their own decisions: consent (
Transaction participant local job execution succeeded) or canceled (local job execution failure).
Phase 2: Commit phase (commit phase)
At this stage, the facilitator will make a decision based on the outcome of the first phase of the vote: Commit or Cancel. When and only if all participants agree to submit to the Coordinator, all participants are notified
Transaction, otherwise the coordinator will notify all participants to cancel the transaction. The action that the contributor will perform the response when it receives a message from the coordinator.
Note that the two-phase commit protocol differs from the two-phase locking protocol, and the two-phase locking protocol is a consistent control protocol.
-------------
Xa
Xa is a two-phase commit protocol defined by the X/open DTP Organization (x/open DTP Group), which is known as many databases (Oracle and DB2) and middleware tools such as CICS and
Tuxedo). Local support.
The X/open DTP Model (1994) includes application (AP), transaction manager (TM), Resource Manager (RM), Communication Resource Manager (CRM) four parts. In this model,
Usually the transaction manager (TM) is the transaction middleware, the Resource Manager (RM) is a database, and the Communication Resource Manager (CRM) is the message middleware.
In general, a database does not know what other databases are doing, so in a DTP environment, transaction middleware is required, and it informs and coordinates the reference of the relevant database
Hand or roll back. A database only alludes its own operations (recoverable) to global transactions.
Xa is the X/open DTP-defined interface specification (i.e. interface function) between the transaction middleware and the database, which is used by the transaction middleware to notify the start, end, and submission of database transactions.
Roll back and so on. The XA interface functions are provided by the database vendor. Normally, the transaction middleware and the database through the XA interface specification, using two-phase commit to complete a global transaction, XA rules
The basis of the van is the two-phase commit protocol.
-------------
Three-phase commit protocol (finite state automata)
http://my.oschina.net/picasso/blog/36572