CN103559245A - Distributed transaction committing failure handling method, device and system - Google Patents
Distributed transaction committing failure handling method, device and system Download PDFInfo
- Publication number
- CN103559245A CN103559245A CN201310522398.0A CN201310522398A CN103559245A CN 103559245 A CN103559245 A CN 103559245A CN 201310522398 A CN201310522398 A CN 201310522398A CN 103559245 A CN103559245 A CN 103559245A
- Authority
- CN
- China
- Prior art keywords
- distributed transaction
- database
- task manager
- subordinate phase
- transaction
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W24/00—Supervisory, monitoring or testing arrangements
- H04W24/04—Arrangements for maintaining operational condition
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Databases & Information Systems (AREA)
- Theoretical Computer Science (AREA)
- Computing Systems (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
An embodiment of the invention provides a distributed transaction committing failure handling method and device. The method includes the steps: recording the state of a distributed transaction as an unfinished state by a first node after committing the distributed transaction at a first stage; transmitting a transaction state query request including the sign of the distributed transaction to a second node according to the recorded unfinished state of the distributed transaction after the first node fails or network connection between the first node and the second node fails and failure recovers; repairing the distributed transaction at a second stage according to the state of the distributed transaction returned by the second node. By the method, the problem that the distributed transaction cannot be automatically repaired when second-stage committing failure of the distributed transaction occurs can be solved, and atomicity and uniformity of the distributed transaction are ensured.
Description
Technical field
The present invention relates to communication network technology field, relate in particular to disposal route, device and system that a kind of distributed transaction is submitted fault to.
Background technology
Affairs (Transaction) be a sequence of operation for realizing the minimum logical unit of work (LUW) of specific transactions function accessing database, conventionally comprise local matter and distributed transaction, claim global transaction again.
Distributed transaction refers to that affairs may relate to a plurality of database manipulations, for example, in affairs, may upgrade several different databases.After these databases are operated, to all submitted or rollbacks of the modification of these databases, submission refers to amended data to be written to disk, rollback refers to cancel to be revised, the database not allowing is submitted to and the not submission of some databases, and this characteristic is called atomicity and the consistance of affairs.Now not only whether dependence operation itself is successful to the own inner submission of doing to operate for a database, whether the operation that also will rely on other database relevant to distributed transaction is successful, if arbitrary operation failure of arbitrary database, participating in all operations that all databases of these affairs do all must rollback.
Generally, a certain database cannot know what other database doing, and therefore, commonly need to introduce a task manager and coordinates to control as transaction middleware, and adopted for two stages completed the submission of a distributed transaction, its detailed process is as follows:
Task manager receives the affairs of application program and submits to after request, notifies each database associated with these affairs to carry out two stage affairs and submits to.
In the first stage, each database of task manager request prepares to submit to affairs branch separately, to be confirmed whether that all Relational databases can submit affairs branch separately to, this first stage submits to and is called pre-submission, and affairs branch is separately called local matter.When a certain database is received after pre-submission request, if can submit one's own affairs branch to, the redo log (Redo Log) to this database by the data operating record of doing in own Gai affairs branch, and agree to replying of submission to one of task manager, but now database is not really submitted these affairs to.Task manager is examined the pre-submission result that each database returns, and as submitted to, task manager requires each database to be submitted to, to enter subordinate phase.If there be pre-submission the to of arbitrary database to return to failure, task manager will require its operation of all other rollback databases, and this distributed transaction is rolled back like this.
In subordinate phase, task manager requires each database execution to be submitted to, and this distributed transaction is submitted like this; Be submitted to be included in and in redo log, record commit operation, and amended data are write to disk, when receiving each database subordinate phase, submit to after successfully response, task manager finishes this distributed transaction, and notification application affairs are submitted to successfully.
But in subordinate phase, for example, when task manager, database failure (machine of delaying suddenly), or network between the two connects when abnormal, may occur that partial database successfully submitted to affairs, partial database not to complete the situation of submission, because each database is separate, state that cannot perception the other side, the database that does not complete submission under this scene will not know how to process unclosed affairs, cause these affairs automatically to repair, thereby the atomicity of affairs and consistance cannot be guaranteed; Or task manager does not receive the subordinate phase submission response that database returns, and causes affairs automatically to repair.Be in prior art, the defect that exists these affairs automatically to repair while breaking down in distributed transaction subordinate phase submission process.
Summary of the invention
The embodiment of the present invention provides a kind of disposal route, device and system of submission fault of distributed transaction, for solving the problem that cannot automatically repair when the submission of distributed transaction subordinate phase is broken down, and atomicity and the consistance of distributed transaction have been guaranteed.
First aspect, the distributed transaction that the embodiment of the present invention provides submits to the disposal route of fault to comprise: after submitting in the first stage that completes distributed transaction, first node records the state of described distributed transaction for not finishing; Described first node fault or described first node are connected after fault and fault recovery with the network between Section Point, according to the state of the distributed transaction of described record for not finishing, to described Section Point, send transaction status inquiry request, the sign that described transaction status inquiry request comprises described distributed transaction, wherein, described first node is task manager, described Section Point is the database associated with described distributed transaction, or, described first node is the database associated with described distributed transaction, and described Section Point is task manager; The state of the described distributed transaction returning according to described Section Point, carries out the reparation of the subordinate phase of described distributed transaction.
In the possible implementation of the first of first aspect, described first node is the database associated with described distributed transaction, and described Section Point is task manager; The state of the described distributed transaction that described Section Point returns is for not finishing, described in carry out the subordinate phase of described distributed transaction reparation comprise that described database carries out the subordinate phase of described distributed transaction and submit to and return to described task manager the result that described subordinate phase is submitted to.
In the possible implementation of the second of first aspect, described first node is task manager, and described Section Point is the database associated with described distributed transaction; The state of the described distributed transaction that described Section Point returns is for not finishing, described in carry out the subordinate phase of described distributed transaction reparation comprise that described task manager sends subordinate phase to described database and submits request to.
In the third possible implementation of first aspect, described first node is task manager, and described Section Point is the database associated with described distributed transaction; The state of the described distributed transaction that described Section Point returns is for completing, described in carry out the subordinate phase of described distributed transaction reparation comprise described task manager judgement other databases associated with described distributed transaction all complete subordinate phase and submit to after the described distributed transaction of termination.
In the 4th kind of possible implementation of first aspect, described first node is task manager, and described Section Point is the database associated with described distributed transaction; The state of the described distributed transaction that described Section Point returns is for failed, described in carry out the subordinate phase of described distributed transaction reparation comprise that described task manager stops described distributed transaction.
In conjunction with the possible implementation of the first of first aspect, in the 5th kind of possible implementation, described database also comprises that the state that records described distributed transaction is for finishing after carrying out the subordinate phase submission of described distributed transaction.
Second aspect, the processing distributed transaction that the embodiment of the present invention provides is submitted the first device of fault to, and described first device is task manager or the database associated with described distributed transaction, comprising:
Record cell, for the state that records described distributed transaction after submitting in the first stage that completes distributed transaction for not finishing;
Transmitting element, for described first device fault or described first device, be connected after fault and fault recovery with the network between the second device, according to the state of the distributed transaction of described recording unit records for not finishing, to described the second device, send transaction status inquiry request, the sign that described transaction status inquiry request comprises described distributed transaction, wherein, when described first device is task manager, described the second device is the database associated with described distributed transaction, when described first device is the database associated with described distributed transaction, described the second device is task manager,
Receiving element, for receiving the state of the described distributed transaction that described the second device returns;
Repair unit, for according to the state of the described distributed transaction of described receiving element reception, carry out the reparation of the subordinate phase of described distributed transaction.
In the possible implementation of the first of first aspect, described first device is the database associated with described distributed transaction, and described the second device is task manager; The state of the described distributed transaction that described the second device returns is not for finishing, described reparation unit, comprises that for carrying out the reparation of the subordinate phase of described distributed transaction the subordinate phase of carrying out described distributed transaction submits to and notify described transmitting element to return to described task manager the result that described subordinate phase is submitted to.
In the possible implementation of the second of first aspect, described first device is task manager, and described the second device is the database associated with described distributed transaction; The state of the described distributed transaction that described the second device returns is for not finishing, and described reparation unit, comprises that for carrying out the reparation of the subordinate phase of described distributed transaction notifying described transmitting element to send subordinate phase to described database submits request to.
In the third possible implementation of first aspect, described first device is task manager, and described the second device is the database associated with described distributed transaction; The state of the described distributed transaction that described the second device returns is for completing, described reparation unit, comprises that for carrying out the reparation of the subordinate phase of described distributed transaction judgement other databases associated with described distributed transaction all complete subordinate phase and submit the rear described distributed transaction that stops to.
In the 4th kind of possible implementation of first aspect, described first device is task manager, and described the second device is the database associated with described distributed transaction; The state of the described distributed transaction that described the second device returns is for failed, and described reparation unit, comprises the described distributed transaction of termination for carrying out the reparation of the subordinate phase of described distributed transaction.
In conjunction with the possible implementation of the first of first aspect, in the 5th kind of possible implementation, described first device also comprises record cell, for carry out the subordinate phase submission of described distributed transaction in described reparation unit after, records the state of described distributed transaction for finishing.
The third aspect, the distributed transaction that the embodiment of the present invention provides submits to the disposal system of fault to comprise: according to arbitrary possible database in second aspect; With according to the arbitrary possible task manager of second aspect.
As can be seen from the above technical solutions, because the embodiment of the present invention is by after submitting in the first stage that completes distributed transaction, first node records the state of described distributed transaction for not finishing; Described first node fault or described first node are connected after fault and fault recovery with the network between Section Point, according to the state of the distributed transaction of described record for not finishing, to described Section Point, send transaction status inquiry request, the sign that described transaction status inquiry request comprises described distributed transaction; The state of the described distributed transaction returning according to described Section Point, carry out the reparation of the subordinate phase of described distributed transaction, realized when subordinate phase be submitted to process in while there is fault distributed transaction can automatically repair, and guarantee atomicity and the consistance of distributed transaction.
Accompanying drawing explanation
In order to be illustrated more clearly in the embodiment of the present invention or technical scheme of the prior art, to the accompanying drawing of required use in embodiment or description of the Prior Art be briefly described below, apparently, accompanying drawing in the following describes is only some embodiments of the present invention, for those of ordinary skills, do not paying under the prerequisite of creative work, can also obtain according to these accompanying drawings other accompanying drawing.
The distributed transaction that Fig. 1 provides for one embodiment of the invention is submitted the process flow figure of fault to;
The distributed transaction that Fig. 2 provides for one embodiment of the invention is submitted the disposal route signaling process figure of fault to;
The distributed transaction that Fig. 3 provides for another embodiment of the present invention is submitted the disposal route signaling process figure of fault to;
The distributed transaction that Fig. 4 provides for another embodiment of the present invention is submitted the disposal route signaling process figure of fault to;
The structure drawing of device of the database that Fig. 5 provides for the embodiment of the present invention;
The structure drawing of device of the task manager that Fig. 6 provides for the embodiment of the present invention;
The structure drawing of device of the database based on computer system that Fig. 7 provides for the embodiment of the present invention;
The structure drawing of device of the task manager based on computer system that Fig. 8 provides for the embodiment of the present invention;
The disposal system structural drawing of the distributed transaction fault that Fig. 9 provides for the embodiment of the present invention.
Embodiment
Below in conjunction with the accompanying drawing in the embodiment of the present invention, the technical scheme in the embodiment of the present invention is clearly and completely described, obviously, described embodiment is only the present invention's part embodiment, rather than whole embodiment.Embodiment based in the present invention, those of ordinary skills, not making the every other embodiment obtaining under creative work prerequisite, belong to the scope of protection of the invention.
The embodiment of the present invention provides distributed transaction to submit the disposal route of fault to, is applied to, in the database or task manager associated with distributed transaction, please refer to Fig. 1, and the method comprises:
Step 101: after submitting in the first stage that completes distributed transaction, first node records the state of described distributed transaction for not finishing.
Wherein, first node is task manager or the database associated with distributed transaction.
Concrete, the state that records described distributed transaction after the first stage that database completes distributed transaction submits to is not for finishing, when task manager receives the first stage that all databases return, submit to after success response, record the state of described distributed transaction for not finishing.
Step 102: first node fault or described first node are connected after fault and fault recovery with the network between Section Point, according to the state of the distributed transaction of described record for not finishing, to described Section Point, send transaction status inquiry request, the sign that described transaction status inquiry request comprises described distributed transaction, wherein, described first node is task manager, described Section Point is the database associated with described distributed transaction, or, described first node is the database associated with described distributed transaction, described Section Point is task manager.
Step 103: the state of the described distributed transaction returning according to described Section Point, carries out the reparation of the subordinate phase of described distributed transaction.
Wherein, when described first node is the database associated with described distributed transaction, described Section Point is task manager, and the state of the described distributed transaction that described Section Point returns is not when finishing, described in carry out the subordinate phase of described distributed transaction reparation comprise that described database carries out the subordinate phase of described distributed transaction and submit to and return to described task manager the result that described subordinate phase is submitted to.
Optionally, after the subordinate phase of carrying out described distributed transaction at described database is submitted to successfully, also comprise that the state that records described distributed transaction is for finishing.
Wherein, when described first node is task manager, described Section Point is the database associated with described distributed transaction, and the state of the described distributed transaction that described Section Point returns is not when finishing, described in carry out the subordinate phase of described distributed transaction reparation comprise that described task manager sends subordinate phase to described database and submits request to.
Wherein, when described first node is task manager, described Section Point is the database associated with described distributed transaction, and the state of the described distributed transaction that described Section Point returns is when finishing, described in carry out the subordinate phase of described distributed transaction reparation comprise described task manager judgement each database associated with described distributed transaction all complete subordinate phase and submit to after the described distributed transaction of termination.
Wherein, when described first node is task manager, described Section Point is the database associated with described distributed transaction, and the state of the described distributed transaction that described Section Point returns is when failure, described in carry out the subordinate phase of described distributed transaction reparation comprise that described task manager stops described distributed transaction.
The embodiment of the present invention provides distributed transaction to submit the disposal route signaling process figure of fault to, please refer to Fig. 2, and in the present embodiment, distributed transaction is completed jointly by database 1 and database 2, and idiographic flow comprises:
Step 201: application program sends distributed transaction to task manager and submits request to, described distributed transaction submits to request to comprise distributed transaction sign.
Concrete, application notification task manager is opened a distributed transaction, and informs and in this distributed transaction of task manager, comprised database 1 and database 2.Task manager respectively notification database 1, database 2 is opened local matter.Database 1,2 is opened after local matter success, the access mode of task manager can be recorded in local REDO daily record, and return to affairs and open successfully to task manager, wherein, the access mode of task manager can be the IP address of task manager ID or task manager.The interface that application program provides by calling data storehouse 1,2 completes after the data modification on described all databases, sends distributed transaction submit request to task manager.
Step 202～203: task manager obtains each database associated with described distributed transaction, be the sign of database 1 and database 2 after, to database 1 and database 2, send first stage submission request, the described first stage submits to request to comprise described distributed transaction sign.
Concrete, the distributed transaction that task manager sends from application program is submitted the sign that gets each database associated with described distributed transaction request to.Optionally, task manager is received after the distributed transaction submission request of application program, first in local REDO daily record, records current transaction status for " the wait first stage has submitted to ", and then notification database 1,2 is done first stage submission.
Wherein, step 202 and step 203 do not have strict sequencing.
Step 204: database 1, after completing described first stage submission, records the state of described distributed transaction for not finishing, and then returns to the first stage to task manager and submits success response to.
Wherein, database 1 is carried out the first stage and is submitted to and specifically comprise: according to described distributed transaction sign, inquire after the local matter corresponding with described distributed transaction, the data operating record that this local matter is done is to the redo log on database 1.
Wherein, the state that database 1 can be by recording described distributed transaction on redo log is not for finishing.Concrete, it is as shown in table 1 that database and task manager can record the redo log template of transaction status:
Table 1 can record the redo log template of transaction status
Wherein, because database and task manager can be preserved redo log, for the ease of distinguishing, the redo log of preserving on task manager is defined as to main Redo daily record, the redo log of preserving on database is defined as to the daily record from Redo, and identify by " principal and subordinate's daily record sign " field, this field value is that 1 expression is the redo log that task manager is preserved, value is that 2 expressions are redo logs that database is preserved.
Wherein, because redo log both can record transaction status, also can record node ID that distributed transaction comprises, i.e. each database ID and the task manager ID associated with described distributed transaction, the data that the redo log of preserving for database can also record modification.Therefore by " Log Types " field, identify, what when this field value is 2, represent this redo log preservation is transaction status.
When " Log Types " value is 2, just there is " transaction status " field, by different values, represent different transaction status.Wherein, for in database, preserve from Redo daily record, possible transaction status value is 1,3,6,7,8, the distributed transaction state on this database of being all illustrated in when value is 1 and 3 is for not finishing, and the distributed transaction state on this database of being all illustrated in when value is 6～8 is for finishing.Wherein, for the main Redo daily record of preserving in task manager, possible transaction status value is 1～8, the distributed transaction state on task manager of being all illustrated in when value is 1～5 is for not finishing, and the distributed transaction state on task manager of being all illustrated in when value is 6～8 is for finishing.
Concrete, the redo log that records transaction status of preserving on database 1 in step 204 is as shown in table 2:
The redo log that records transaction status that table 2 database 1 is preserved
| Field name | Value |
| Distributed transaction sign | Trans_ID1 |
| Principal and subordinate's daily record sign | 2 |
| Log Types | 2 |
| Transaction status | 3 |
Step 205: database 2 is after completing described first stage submission, and the state that records described distributed transaction is that 3 " first stage has submitted to " represent that distributed transaction does not finish, and then returns to the first stage to task manager and submits success response to.
Wherein, the operation that in step 205, performed operation refer step 204 databases 1 of database 2 are carried out, the transaction status of record is as shown in table 2.And step 204 and step 205 do not have strict sequencing.
Step 206: task manager is determined after the first stage submission success response that receives database 1 and database 2, recorded the state of described distributed transaction for not finishing.
Wherein, the state that task manager can be by recording described distributed transaction on redo log is not for finishing.As shown in table 1 for preserving the template of redo log of distributed transaction state, the description of the implication of parameters and value refer step 204.The redo log that comprises transaction status that in step 206, task manager is preserved is as shown in table 3:
The redo log that records transaction status that table 3 task manager is preserved
| Field name | Value |
| Distributed transaction sign | Trans_ID1 |
| Principal and subordinate's daily record sign | 1 |
| Log Types | 2 |
| Transaction status | 4 |
Step 207～208: task manager sends subordinate phase submission request to database 1 and database 2, described subordinate phase submits to request to comprise described distributed transaction sign.
Wherein, step 207 and step 208 do not have strict sequencing.
Step 209: database 2, after completing described subordinate phase submission, returns to subordinate phase to task manager and submits success response to.
Wherein, database 2 execution subordinate phase are submitted to be specially according to described distributed transaction sign and are inquired after the local matter corresponding with described distributed transaction, in redo log, record commit operation, and the amended data of this local matter are written to disk.
Wherein, task manager receives after this subordinate phase is submitted success response to and can in internal memory, complete subordinate phase submission by database of record 2.
Optionally, database 2, after completing subordinate phase submission, can also record the state of described distributed transaction for finishing.Concrete, database 2 is updated to 6. " subordinate phase has been submitted to " by the transaction status value in redo log, indicates the state of distributed transaction described in this database for finishing, as shown in table 4:
The redo log that records transaction status after table 4 database 2 upgrades
| Field name | Value |
| Distributed transaction sign | Trans_ID1 |
| Principal and subordinate's daily record sign | 2 |
| Log Types | 2 |
| Transaction status | 6 |
Step 210: the network between rear database 1 fault of step 204 or database 1 and task manager connects fault, therefore not completing subordinate phase submits to, after fault recovery, determine and have unclosed described distributed transaction, to task manager, send transaction status inquiry request, described transaction status inquiry request comprises described distributed transaction sign.
Wherein, can to be between step 204 and step 207 submit request to because powered-off fault or the suddenly machine of delaying cause database 1 not receive subordinate phase to database 1 fault, can be also step 207 receive subordinate phase submit request to after powered-off fault or suddenly the machine of delaying cause database 1 subordinate phase to be submitted to not having complete.When database 1 re-power or system normal after fault recovery.
Wherein, network between database 1 and task manager connects fault and is specially task manager between step 204 and step 207 and is connected and breaks down with network between database 1, cause database 1 not receive subordinate phase and submit request to, when network connects fault recovery, can be detected by database 1 with task manager between can normally be connected.
Concrete, the redo log that database 1 can be preserved by accessing step 204, the state of determining distributed transaction for " 3. the first stage has submitted " according to the transaction status value of the record of redo log shown in table 2 is for not finishing, and obtains distributed transaction and identify.
Concrete, the message structure of the transaction status inquiry request that database 1 sends to task manager is as shown in table 5:
The message structure of table 5 transaction status inquiry request
Step 211: task manager returns to the state of described distributed transaction to database 1.
Concrete, task manager can accessing step 206 redo logs of preserving, by redo log shown in table 3, obtaining transaction status value is 4 " wait subordinate phase has been submitted to ", and its implication is that wait subordinate phase has been submitted to, and returns to described transaction status value to database 1.
Concrete, the message structure of the transaction status response that task manager returns to database 1 is as shown in table 6:
The message structure of table 6 transaction status response
Step 212: the state of the distributed transaction that database 1 returns according to task manager, for not finishing, is carried out the subordinate phase of described distributed transaction and submitted to, and sends subordinate phase submission result to task manager.
Concrete, the state value of the distributed transaction that database 1 returns according to task manager be 4 " wait for subordinate phase submitted to " determine described distributed transaction state for not finishing.
Optionally, after database 1 is carried out the subordinate phase submission of described distributed transaction, the state that can also record described distributed transaction is oneself end.Concrete, after database 1 completes subordinate phase submission, the transaction status value of redo log described in table 2 is updated to 6 " subordinate phase has been submitted to ", as shown in table 4, describedly to task manager, send subordinate phase and submit to result specifically to comprise: to task manager, send subordinate phase and submits successfully and indicate.After database 1 execution subordinate phase is submitted to unsuccessfully, the transaction status value of redo log is updated to 7 " subordinate phase is submitted to unsuccessfully ", describedly to task manager, sends subordinate phase and submit to result specifically to comprise: to task manager, send subordinate phase and submits unsuccessfully and indicate.
Step 213: task manager receives subordinate phase that database 1 returns submit result to after, the subordinate phase of returning according to database 1 and database 2 is submitted response to, stops distributed transaction, and to application program, returns to distributed transaction and submit the response finishing to.
Concrete, when receiving the subordinate phase that step 212 database 1 returns, submits to after successfully indication task manager, because database 2 has returned to subordinate phase and has submitted success response in step 209, thereby specified data storehouse 1 and database 2 have all completed subordinate phase submission, to application program, return to distributed transaction and submit successfully response to.
Concrete, when receiving the subordinate phase that step 212 database 1 returns, submits to after unsuccessfully indication task manager, because unsuccessfully just can stop affairs and cannot automatically repair as long as exist a database subordinate phase to submit to, therefore directly to application program, returning to distributed transaction submits failed response to.
So far, all submission flow processs of this distributed transaction finish.
By this embodiment, can solve when task manager sends subordinate phase submission request, because database failure or database are connected fault and cause database cannot receive subordinate phase submitting request to network between task manager, thereby the problem that affairs cannot be repaired automatically, has further guaranteed atomicity and the consistance of affairs.
Another embodiment of the present invention provides distributed transaction to submit the disposal route signaling process figure of fault to, please refer to Fig. 3, and in the present embodiment, distributed transaction is completed jointly by database 1 and database 2, and idiographic flow comprises:
Step 301: application program sends distributed transaction to task manager and submits request to, described distributed transaction submits to request to comprise distributed transaction sign.
The step 201 of the detailed descriptionwith reference 2 corresponding embodiment of this step.
Step 302～303: task manager obtains after the sign of database 1 and database 2, send first stage submission request to database 1 and database 2, and the described first stage submits to request to comprise described distributed transaction sign.
Step 202～203 of the detailed descriptionwith reference 2 corresponding embodiment of this step.
Step 304～305: database 1 and database 2, after completing described first stage submission, record the state of described distributed transaction for not finishing, and then return to the first stage to task manager and submit success response to.
Step 204～205 of the detailed descriptionwith reference 2 corresponding embodiment of this step.
Step 306: task manager is determined after the first stage submission success response that receives database 1 and database 2, recorded the state of described distributed transaction for not finishing.The step 206 of the detailed descriptionwith reference 2 corresponding embodiment of this step.
Step 307: task manager sends subordinate phase to database 1 and submits request to, described subordinate phase submits to request to comprise described distributed transaction sign.
Step 308: database 1 is carried out the subordinate phase of described distributed transaction and submitted to, records and to task manager, sends subordinate phase after the state of described distributed transaction and submit response to.
In first example of the present embodiment, this step is specially: database 1 successful execution subordinate phase is submitted to, after database 1 completes subordinate phase submission, transaction status value in the redo log of preserving in step 304 is updated to 6, represent " subordinate phase has been submitted to ", as shown in table 4 after upgrading, to task manager, send subordinate phase and submit success response to.
In second example of the present embodiment, this step is specially: database 1 is carried out subordinate phase and submitted to unsuccessfully, after database 1 execution subordinate phase is submitted to unsuccessfully, transaction status value in the redo log of preserving in step 304 is updated to 7 " subordinate phase is submitted to unsuccessfully ", to task manager, sends subordinate phase and submit failure response to.
Task manager fault after step 307, does not therefore successfully send subordinate phase submission request and does not receive the subordinate phase that in step 308, database 1 returns to database 2 and submit response to.Wherein, task manager fault can be powered-off fault or the machine of delaying, when re-power or system normal after fault recovery.
Step 309～310: task manager is determined and had unclosed distributed transaction after fault recovery, sends transaction status inquiry request to database 1 and database 2, and described global transaction status query request comprises described distributed transaction sign.
Concrete, the redo log that task manager can be preserved by step 306, as transaction status value in table 3 be 4 states of determining distributed transactions for not finishing, and obtain distributed transaction and identify.
Concrete, the message structure of the transaction status inquiry request that task manager sends to database 1 and database 2 is with reference to the step 219 of figure 2 corresponding embodiment, as shown in table 5.
Step 311: database 2 returns to the state of described distributed transaction to task manager.
Concrete database 2 can accessing step transaction status value in 305 redo logs of preserving be 3 " first stage has submitted to ", and return to described transaction status value to task manager.
Step 312: the state of the distributed transaction that task manager returns according to database 2, for not finishing, resends subordinate phase to database 2 and submits request to.
Concrete, the state value of the distributed transaction that task manager returns according to database 2 is that 3 states of determining described distributed transaction are not for finishing.
Step 313: database 2 completes the subordinate phase of described distributed transaction and submits to, records the state of described distributed transaction for completing, and send subordinate phase submission success response to task manager.
Step 314: database 1 returns to the state of described distributed transaction to task manager.
Concrete database 1 can accessing step transaction status value in 308 redo logs of preserving, and return to described transaction status value to task manager.
Step 315: the subordinate phase that task manager returns according to database 1 and database 2 is submitted response to, stops described distributed transaction, and returns to response to application program.
When task manager receives after the response message that database 1 returns by step 314, in first example of the present embodiment, the state value of the distributed transaction that database 1 returns is 6 " subordinate phase has been submitted to ", be that the state of distributed transaction is for completing, task manager according to the state of described distributed transaction for completing, judge other databases associated with distributed transaction, be whether database 2 completes subordinate phase submission, if it is stop described distributed transaction, and return to submission success response to application program, this flow process finishes.Otherwise stop described distributed transaction after receiving the submission response that database 2 returns.
In second example of the present embodiment, the state value of the distributed transaction that database 1 returns is 7 " subordinate phase is submitted to unsuccessfully ", be that the state of distributed transaction is for failed, task manager according to the state of described distributed transaction for failed, stop immediately described distributed transaction, and return to submission failure response to application program, this flow process finishes.
By this embodiment, can solve because task manager fault, successfully do not send subordinate phase and submit the problem of asking or successfully not receiving subordinate phase submission response and cause affairs automatically to repair to, and guaranteed atomicity and the consistance of affairs.
Another embodiment of the present invention provides distributed transaction to submit the disposal route signaling process figure of fault to, please refer to Fig. 4, and in the present embodiment, distributed transaction is completed jointly by database 1 and database 2, and idiographic flow comprises:
Step 401: application program sends distributed transaction to task manager and submits request to, described distributed transaction submits to request to comprise distributed transaction sign.
The step 201 of the detailed descriptionwith reference 2 corresponding embodiment of this step.
Step 402～403: task manager obtains after the sign of database 1 and database 2, send first stage submission request to database 1 and database 2, and the described first stage submits to request to comprise described distributed transaction sign.
Step 202～203 of the detailed descriptionwith reference 2 corresponding embodiment of this step.
Step 404～405: database 1 and database 2, after completing described first stage submission, record the state of described distributed transaction for not finishing, and then return to the first stage to task manager and submit success response to.
Step 204～205 of the detailed descriptionwith reference 2 corresponding embodiment of this step.
Step 406: task manager is determined after the first stage submission success response that receives database 1 and database 2, recorded the state of described distributed transaction for not finishing.The step 206 of the detailed descriptionwith reference 2 corresponding embodiment of this step.
Step 407～408: task manager sends subordinate phase submission request to database 1 and database 2, described subordinate phase submits to request to comprise described distributed transaction sign.
Wherein, step 407 and step 408 do not have strict sequencing.
In first example of the present embodiment, the network after step 404 and before 407 between task manager and database 1 connects fault, so database 1 does not receive the subordinate phase that step 407 sends and submits request to.
In second example of the present embodiment, the network after step 408 between task manager and database 2 connects fault.Following steps 409 are for second example of the present embodiment.
Step 409: database 2 is carried out the subordinate phase of described distributed transaction and submitted to, records and to task manager, sends subordinate phase after the state of described distributed transaction and submit response to.
In second example of the present embodiment, the network after step 408 between task manager and database 2 connects fault, so task manager does not receive the subordinate phase submission response that step 409 is returned.
This step is specially: database 2 successful execution subordinate phase are submitted to, after database 2 completes subordinate phase submission, transaction status value in the redo log of preserving in step 405 is updated to 6 " subordinate phase has been submitted to ", as shown in table 4 after upgrading, to task manager, send subordinate phase and submit success response to.Or be specially: database 2 is carried out subordinate phase and submitted to unsuccessfully, after database 2 execution subordinate phase are submitted to unsuccessfully, transaction status value in the redo log of preserving in step 405 is updated to 7 " subordinate phase is submitted to unsuccessfully ", to task manager, sends subordinate phase and submit failure response to.
Wherein, first example of following steps 410～413 corresponding the present embodiment, second example of the corresponding the present embodiment in step 414～415.
Step 410: the network between task manager and database 1 connects after fault recovery, determines and has unclosed distributed transaction, to database 1, sends transaction status inquiry request, and described transaction status inquiry request comprises described distributed transaction sign.
Concrete, the redo log that task manager can be preserved by step 306, as transaction status value in table 3 be 4 states of determining distributed transactions for not finishing, and obtain distributed transaction and identify.
Step 411: database 1 returns to the state of described distributed transaction to task manager.
Concrete database 1 can accessing step transaction status value in 404 redo logs of preserving be 3, and return to described transaction status value to task manager.
Step 412: the state of the distributed transaction that task manager returns according to database 1, for not finishing, resends subordinate phase to database 1 and submits request to.
Concrete, the state value of the distributed transaction that task manager returns according to database 1 is that 3 states of determining described distributed transaction are not for finishing.
Step 413: database 2 completes the subordinate phase of described distributed transaction and submits to, records the state of described distributed transaction for completing, and send subordinate phase submission success response to task manager.
Step 414: the network between task manager and database 2 connects after fault recovery, determines and has unclosed distributed transaction, to database 2, sends transaction status inquiry request, and described transaction status inquiry request comprises described distributed transaction sign.
Concrete, the redo log that task manager can be preserved by step 306, as transaction status value in table 3 be 4 states of determining distributed transactions for not finishing, and obtain distributed transaction and identify.
Step 415: database 2 returns to the state of described distributed transaction to task manager.
Concrete database 2 can accessing step transaction status value in 409 redo logs of preserving, and return to described transaction status value to task manager.
Step 416: the subordinate phase that task manager returns according to database 1 and database 2 is submitted response to, stops described distributed transaction, and returns to response to application program.
In first example of the present embodiment, task manager receives the subordinate phase that step 413 database 1 returns and submits to after success response, judge whether each database associated with distributed transaction all completes subordinate phase and submit to, if it is stop described distributed transaction, and return to submission success response to application program, this flow process finishes.
In second example of the present embodiment, when the state value that receives the distributed transaction that step 415 database 2 returns when task manager is 6 " subordinate phase has been submitted to ", be that the state of distributed transaction is for completing, task manager according to the state of described distributed transaction for completing, judge other databases associated with distributed transaction, be whether database 1 all completes subordinate phase submission, if it is stop described distributed transaction, and return to submission success response to application program, this flow process finishes.Otherwise, if also completing subordinate phase, do not submit to database 1, after the submission response that receives database 1, stop again described distributed transaction.Or when the state value that receives the distributed transaction that step 415 database 2 returns when task manager is 7 " subordinate phase is submitted to unsuccessfully ", be that the state of distributed transaction is for failed, task manager according to the state of described distributed transaction for failed, stop immediately described distributed transaction, and return to submission failure response to application program, this flow process finishes.
By this embodiment, can solve because network is connected fault between task manager and database, successfully do not send subordinate phase and submit the problem of asking or successfully not receiving subordinate phase submission response and cause affairs automatically to repair to, and guaranteed atomicity and the consistance of affairs.
One embodiment of the invention provides for submitting the database of distributed transaction to, please refer to Fig. 5, and this database 500 comprises:
Transmitting element 502, for database failure or database, be connected after fault and fault recovery with the network between task manager, the state of the distributed transaction recording according to record cell 501 is not for finishing, to task manager, send transaction status inquiry request, the sign that described transaction status inquiry request comprises described distributed transaction;
Receiving element 503, for receiving the state of the described distributed transaction that task manager returns;
Optionally, the state of the described distributed transaction that described task manager returns is not for finishing, repair unit 504, for carrying out the reparation of the subordinate phase of described distributed transaction, comprise: the subordinate phase of carrying out described distributed transaction is submitted to and notifies transmitting element 502 to return to described task manager the result that described subordinate phase is submitted to; Optionally, record cell 503, further, also for carry out the subordinate phase submission of described distributed transaction in described reparation unit after, records the state of described distributed transaction for finishing.
One embodiment of the invention provides for submitting the task manager of distributed transaction to, please refer to Fig. 6, and this task manager 600 comprises:
Transmitting element 502, for database failure or database, be connected after fault and fault recovery with the network between task manager, the state of the distributed transaction recording according to record cell 501 is not for finishing, to task manager, send transaction status inquiry request, the sign that described transaction status inquiry request comprises described distributed transaction;
Receiving element 503, for receiving the state of the described distributed transaction that task manager returns;
Optionally, the state of the described distributed transaction that database returns, for not finishing, is repaired unit 504, for carrying out the reparation of the subordinate phase of described distributed transaction, comprises: notify described transmitting element to send subordinate phase to described database and submit request to.
Optionally, the state of the described distributed transaction that database returns is for completing, repair unit 504, for carrying out the reparation of the subordinate phase of described distributed transaction, comprise: judge that other databases associated with described distributed transaction all complete subordinate phase and submit the rear described distributed transaction that stops to.
Optionally, the state of the described distributed transaction that database returns, for failed, is repaired unit 504, comprises: stop described distributed transaction for carrying out the reparation of the subordinate phase of described distributed transaction.
The embodiment of the present invention realize the function of each step that each unit in database that distributed transaction submits to and task manager is respectively used to realize the commit method of aforementioned distributed transaction, due in preceding method embodiment, each step is had been described in detail, do not repeat them here.
Database in the embodiment of the present invention can be realized based on computer system, and the method shown in Fig. 1, Fig. 2, Fig. 3, Fig. 4 all can realize at the database based on computer system.Fig. 7 shows the embodiment of the database of realizing based on computer system.In the present embodiment, database can comprise: processor 701, storer 702 and communication interface 703, wherein:
Wherein, processor 701 can be central processing unit (central processing unit, CPU), special IC (application-specific integrated circuit, ASIC) etc.Wherein, the database in the present embodiment can comprise bus 704.Between processor 701, storer 702 and communication interface 703, can connect and communicate by letter by bus 704.Wherein, storer 702 can comprise: random access memory (random access memory, RAM), and ROM (read-only memory) (read-only memory, ROM), disks etc. have the entity of memory function.
Each step of the database that processor 701 can also be described for manner of execution embodiment Fig. 1, Fig. 2, Fig. 3, Fig. 4, the embodiment of the present invention is not described in detail in this.
Task manager in the embodiment of the present invention can be realized based on computer system, and the method shown in Fig. 1, Fig. 2, Fig. 3, Fig. 4 all can realize at the task manager based on computer system.Fig. 8 shows the embodiment of the task manager of realizing based on computer system.In the present embodiment, server can comprise: processor 801, storer 802 and communication interface 803, wherein:
Wherein, processor 801 can be central processing unit (central processing unit, CPU), special IC (application-specific integrated circuit, ASIC) etc.Wherein, the server in the present embodiment can comprise bus 804.Between processor 801, storer 802 and communication interface 803, can connect and communicate by letter by bus 804.Wherein, storer 802 can comprise: random access memory (random access memory, RAM), and ROM (read-only memory) (read-only memory, ROM), disks etc. have the entity of memory function.
Each step of the task manager that processor 801 can also be described for manner of execution embodiment Fig. 1, Fig. 2, Fig. 3, Fig. 4, the embodiment of the present invention is not described in detail in this.
The embodiment of the present invention provides a kind of submission system of distributed transaction, referring to Fig. 9, comprising: the task manager 600 described in the database 500 described in above-mentioned arbitrary embodiment and above-mentioned arbitrary embodiment.Wherein, at least there is the first database 5001 and the second database 5002. in database 500
To a kind of being described in detail provided by the present invention, having applied specific case herein principle of the present invention and embodiment are set forth above, the explanation of above embodiment is just for helping to understand method of the present invention and core concept thereof; , for one of ordinary skill in the art, according to thought of the present invention, all will change in specific embodiments and applications, in sum, this description should not be construed as limitation of the present invention meanwhile.
Claims (13)
1. distributed transaction is submitted a disposal route for fault to, it is characterized in that, described method comprises:
After submitting in the first stage that completes distributed transaction, first node records the state of described distributed transaction for not finishing;
Described first node fault or described first node are connected after fault and fault recovery with the network between Section Point, according to the state of the distributed transaction of described record for not finishing, to described Section Point, send transaction status inquiry request, the sign that described transaction status inquiry request comprises described distributed transaction, wherein, described first node is task manager, described Section Point is the database associated with described distributed transaction, or, described first node is the database associated with described distributed transaction, and described Section Point is task manager;
The state of the described distributed transaction returning according to described Section Point, carries out the reparation of the subordinate phase of described distributed transaction.
2. method according to claim 1, is characterized in that:
Described first node is the database associated with described distributed transaction, and described Section Point is task manager;
The state of the described distributed transaction that described Section Point returns is for not finishing, described in carry out the subordinate phase of described distributed transaction reparation comprise that described database carries out the subordinate phase of described distributed transaction and submit to and return to described task manager the result that described subordinate phase is submitted to.
3. method according to claim 2, is characterized in that:
Described database also comprises that the state that records described distributed transaction is for finishing after carrying out the subordinate phase submission of described distributed transaction.
4. method according to claim 1, is characterized in that:
Described first node is task manager, and described Section Point is the database associated with described distributed transaction;
The state of the described distributed transaction that described Section Point returns is for not finishing, described in carry out the subordinate phase of described distributed transaction reparation comprise that described task manager sends subordinate phase to described database and submits request to.
5. method according to claim 1, is characterized in that:
Described first node is task manager, and described Section Point is the database associated with described distributed transaction;
The state of the described distributed transaction that described Section Point returns is for completing, described in carry out the subordinate phase of described distributed transaction reparation comprise described task manager judgement other databases associated with described distributed transaction all complete subordinate phase and submit to after the described distributed transaction of termination.
6. method according to claim 1, is characterized in that:
Described first node is task manager, and described Section Point is the database associated with described distributed transaction;
The state of the described distributed transaction that described Section Point returns is for failed, described in carry out the subordinate phase of described distributed transaction reparation comprise that described task manager stops described distributed transaction.
7. process distributed transaction and submit a first device for fault to, described first device is task manager or the database associated with described distributed transaction, it is characterized in that, described first device comprises:
Record cell, for the state that records described distributed transaction after submitting in the first stage that completes distributed transaction for not finishing;
Transmitting element, for described first device fault or described first device, be connected after fault and fault recovery with the network between the second device, according to the state of the distributed transaction of described recording unit records for not finishing, to described the second device, send transaction status inquiry request, the sign that described transaction status inquiry request comprises described distributed transaction, wherein, when described first device is task manager, described the second device is the database associated with described distributed transaction, when described first device is the database associated with described distributed transaction, described the second device is task manager,
Receiving element, for receiving the state of the described distributed transaction that described the second device returns;
Repair unit, for according to the state of the described distributed transaction of described receiving element reception, carry out the reparation of the subordinate phase of described distributed transaction.
8. first device according to claim 7, is characterized in that:
Described first device is the database associated with described distributed transaction, and described the second device is task manager;
The state of the described distributed transaction that described the second device returns is not for finishing, described reparation unit, comprises that for carrying out the reparation of the subordinate phase of described distributed transaction the subordinate phase of carrying out described distributed transaction submits to and notify described transmitting element to return to described task manager the result that described subordinate phase is submitted to.
9. first device according to claim 8, is characterized in that, also comprises:
Record cell, for carry out the subordinate phase submission of described distributed transaction in described reparation unit after, records the state of described distributed transaction for finishing.
10. first device according to claim 7, is characterized in that:
Described first device is task manager, and described the second device is the database associated with described distributed transaction;
The state of the described distributed transaction that described the second device returns is for not finishing, and described reparation unit, comprises that for carrying out the reparation of the subordinate phase of described distributed transaction notifying described transmitting element to send subordinate phase to described database submits request to.
11. first devices according to claim 7, is characterized in that:
Described first device is task manager, and described the second device is the database associated with described distributed transaction;
The state of the described distributed transaction that described the second device returns is for completing, described reparation unit, comprises that for carrying out the reparation of the subordinate phase of described distributed transaction judgement other databases associated with described distributed transaction all complete subordinate phase and submit the rear described distributed transaction that stops to.
12. first devices according to claim 7, is characterized in that:
Described first device is task manager, and described the second device is the database associated with described distributed transaction;
The state of the described distributed transaction that described the second device returns is for failed, and described reparation unit, comprises the described distributed transaction of termination for carrying out the reparation of the subordinate phase of described distributed transaction.
13. 1 kinds of distributed transactions are submitted the disposal system of fault to, it is characterized in that, described system comprises:
According to 7 to 12 arbitrary described databases in claim; With
According to 7 to 12 arbitrary described task managers in claim.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201310522398.0A CN103559245A (en) | 2013-10-29 | 2013-10-29 | Distributed transaction committing failure handling method, device and system |
| PCT/CN2014/074595 WO2015062200A1 (en) | 2013-10-29 | 2014-04-02 | Method, apparatus, and system for processing distributed transaction submission faults |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201310522398.0A CN103559245A (en) | 2013-10-29 | 2013-10-29 | Distributed transaction committing failure handling method, device and system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN103559245A true CN103559245A (en) | 2014-02-05 |
Family
ID=50013492
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201310522398.0A Pending CN103559245A (en) | 2013-10-29 | 2013-10-29 | Distributed transaction committing failure handling method, device and system |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN103559245A (en) |
| WO (1) | WO2015062200A1 (en) |
Cited By (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103995868A (en) * | 2014-05-20 | 2014-08-20 | 科大国创软件股份有限公司 | Distributed system oriented global transaction manager and transaction handling method |
| WO2015062200A1 (en) * | 2013-10-29 | 2015-05-07 | 华为技术有限公司 | Method, apparatus, and system for processing distributed transaction submission faults |
| CN105786592A (en) * | 2014-12-15 | 2016-07-20 | 北大方正集团有限公司 | Method and device for processing distributed transactions |
| CN105893395A (en) * | 2015-01-26 | 2016-08-24 | 阿里巴巴集团控股有限公司 | Message re-checking method and system of distributed transaction |
| CN105989133A (en) * | 2015-02-25 | 2016-10-05 | 阿里巴巴集团控股有限公司 | Transaction processing method and device |
| CN106598992A (en) * | 2015-10-15 | 2017-04-26 | 中兴通讯股份有限公司 | Database operating method and device |
| CN106960136A (en) * | 2016-01-08 | 2017-07-18 | 阿里巴巴集团控股有限公司 | Signing collision detection method and device |
| CN107332906A (en) * | 2017-06-30 | 2017-11-07 | 郑州云海信息技术有限公司 | Distributed system office management method and device |
| WO2018000811A1 (en) * | 2016-06-29 | 2018-01-04 | 华为技术有限公司 | Fault querying processing method and processing apparatus |
| CN108491252A (en) * | 2018-03-13 | 2018-09-04 | 万惠投资管理有限公司 | distributed transaction processing method and distributed system |
| CN108733457A (en) * | 2018-04-12 | 2018-11-02 | 阿里巴巴集团控股有限公司 | The implementation method and device of distributed transaction |
| CN108762895A (en) * | 2018-05-17 | 2018-11-06 | 阿里巴巴集团控股有限公司 | Handle the method and device of distributed transaction |
| CN110032428A (en) * | 2019-02-21 | 2019-07-19 | 阿里巴巴集团控股有限公司 | The execution method and apparatus of distributed transaction |
| CN110413687A (en) * | 2019-05-09 | 2019-11-05 | 国网冀北电力有限公司 | The distributed transaction fault handling method and relevant device of verification are mutually demonstrate,proved based on node |
| CN112765126A (en) * | 2020-12-31 | 2021-05-07 | 金蝶软件（中国）有限公司 | Database transaction management method and device, computer equipment and storage medium |
| CN112866316A (en) * | 2019-11-27 | 2021-05-28 | 北京沃东天骏信息技术有限公司 | Distributed transaction processing method and device |
| US11934388B2 (en) * | 2019-08-23 | 2024-03-19 | Capital One Services, Llc | Transaction processing failover |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070239719A1 (en) * | 2003-12-04 | 2007-10-11 | International Business Machines Corporation | High performance support for xa protocols in a clustered shared database |
| US20090300405A1 (en) * | 2008-05-29 | 2009-12-03 | Mark Cameron Little | Backup coordinator for distributed transactions |
| CN102317913A (en) * | 2011-07-30 | 2012-01-11 | 华为技术有限公司 | Transaction recovery method and apparatus |
| US20120166407A1 (en) * | 2010-12-28 | 2012-06-28 | Juchang Lee | Distributed Transaction Management Using Two-Phase Commit Optimization |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102073540B (en) * | 2010-12-15 | 2013-05-08 | 北京新媒传信科技有限公司 | Distributed affair submitting method and device thereof |
| US8935205B2 (en) * | 2011-11-16 | 2015-01-13 | Sap Ag | System and method of performing snapshot isolation in distributed databases |
| CN103559245A (en) * | 2013-10-29 | 2014-02-05 | 华为技术有限公司 | Distributed transaction committing failure handling method, device and system |
-
2013
- 2013-10-29 CN CN201310522398.0A patent/CN103559245A/en active Pending
-
2014
- 2014-04-02 WO PCT/CN2014/074595 patent/WO2015062200A1/en active Application Filing
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070239719A1 (en) * | 2003-12-04 | 2007-10-11 | International Business Machines Corporation | High performance support for xa protocols in a clustered shared database |
| US20090300405A1 (en) * | 2008-05-29 | 2009-12-03 | Mark Cameron Little | Backup coordinator for distributed transactions |
| US20120166407A1 (en) * | 2010-12-28 | 2012-06-28 | Juchang Lee | Distributed Transaction Management Using Two-Phase Commit Optimization |
| CN102317913A (en) * | 2011-07-30 | 2012-01-11 | 华为技术有限公司 | Transaction recovery method and apparatus |
Non-Patent Citations (1)
| Title |
|---|
| 刘志峰: "分布事务监控器的恢复处理研究", 《中国优秀硕士学位论文全文数据库信息科技辑》 * |
Cited By (27)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2015062200A1 (en) * | 2013-10-29 | 2015-05-07 | 华为技术有限公司 | Method, apparatus, and system for processing distributed transaction submission faults |
| CN103995868B (en) * | 2014-05-20 | 2017-07-21 | 科大国创软件股份有限公司 | The global transaction manager and transaction methods of Based on Distributed system |
| CN103995868A (en) * | 2014-05-20 | 2014-08-20 | 科大国创软件股份有限公司 | Distributed system oriented global transaction manager and transaction handling method |
| CN105786592A (en) * | 2014-12-15 | 2016-07-20 | 北大方正集团有限公司 | Method and device for processing distributed transactions |
| CN105893395B (en) * | 2015-01-26 | 2019-04-02 | 阿里巴巴集团控股有限公司 | The message of distributed transaction returns checking method and its system |
| CN105893395A (en) * | 2015-01-26 | 2016-08-24 | 阿里巴巴集团控股有限公司 | Message re-checking method and system of distributed transaction |
| CN105989133A (en) * | 2015-02-25 | 2016-10-05 | 阿里巴巴集团控股有限公司 | Transaction processing method and device |
| CN105989133B (en) * | 2015-02-25 | 2019-10-01 | 阿里巴巴集团控股有限公司 | Transaction methods and device |
| CN106598992A (en) * | 2015-10-15 | 2017-04-26 | 中兴通讯股份有限公司 | Database operating method and device |
| CN106598992B (en) * | 2015-10-15 | 2020-10-23 | 南京中兴软件有限责任公司 | Database operation method and device |
| CN106960136A (en) * | 2016-01-08 | 2017-07-18 | 阿里巴巴集团控股有限公司 | Signing collision detection method and device |
| US10866866B2 (en) | 2016-06-29 | 2020-12-15 | Huawei Technologies Co., Ltd. | Query fault processing method and processing apparatus |
| WO2018000811A1 (en) * | 2016-06-29 | 2018-01-04 | 华为技术有限公司 | Fault querying processing method and processing apparatus |
| US11461195B2 (en) | 2016-06-29 | 2022-10-04 | Huawei Technologies Co., Ltd. | Query fault processing method and processing apparatus |
| CN107332906A (en) * | 2017-06-30 | 2017-11-07 | 郑州云海信息技术有限公司 | Distributed system office management method and device |
| CN108491252A (en) * | 2018-03-13 | 2018-09-04 | 万惠投资管理有限公司 | distributed transaction processing method and distributed system |
| CN108491252B (en) * | 2018-03-13 | 2022-03-22 | 万惠投资管理有限公司 | Distributed transaction processing method and distributed system |
| CN108733457B (en) * | 2018-04-12 | 2021-07-20 | 创新先进技术有限公司 | Method and device for realizing distributed transaction |
| CN108733457A (en) * | 2018-04-12 | 2018-11-02 | 阿里巴巴集团控股有限公司 | The implementation method and device of distributed transaction |
| CN108762895A (en) * | 2018-05-17 | 2018-11-06 | 阿里巴巴集团控股有限公司 | Handle the method and device of distributed transaction |
| CN108762895B (en) * | 2018-05-17 | 2021-11-19 | 创新先进技术有限公司 | Method and device for processing distributed transaction |
| CN110032428A (en) * | 2019-02-21 | 2019-07-19 | 阿里巴巴集团控股有限公司 | The execution method and apparatus of distributed transaction |
| CN110032428B (en) * | 2019-02-21 | 2023-06-27 | 创新先进技术有限公司 | Method and device for executing distributed transaction |
| CN110413687A (en) * | 2019-05-09 | 2019-11-05 | 国网冀北电力有限公司 | The distributed transaction fault handling method and relevant device of verification are mutually demonstrate,proved based on node |
| US11934388B2 (en) * | 2019-08-23 | 2024-03-19 | Capital One Services, Llc | Transaction processing failover |
| CN112866316A (en) * | 2019-11-27 | 2021-05-28 | 北京沃东天骏信息技术有限公司 | Distributed transaction processing method and device |
| CN112765126A (en) * | 2020-12-31 | 2021-05-07 | 金蝶软件（中国）有限公司 | Database transaction management method and device, computer equipment and storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2015062200A1 (en) | 2015-05-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN103559245A (en) | Distributed transaction committing failure handling method, device and system | |
| WO2016180164A1 (en) | Method and apparatus for rolling back distributed transaction | |
| KR102072726B1 (en) | Systems and methods for supporting inline delegation of middle-tier transaction logs to database | |
| US6671704B1 (en) | Method and apparatus for handling failures of resource managers in a clustered environment | |
| WO2017063520A1 (en) | Method and apparatus for operating database | |
| US11310130B2 (en) | Heartbeat information sending method and apparatus, and heartbeat sending node | |
| CN110032428B (en) | Method and device for executing distributed transaction | |
| CN110569149A (en) | method for triggering automatic emergency switching of Oracle disaster tolerance based on fault detection | |
| CN111209142A (en) | Cross-database transaction management method, device, equipment and storage medium | |
| CN102317913B (en) | A kind of transaction recovery method and transaction recovery device | |
| CN111753013A (en) | Distributed transaction processing method and device | |
| US10282457B1 (en) | Distributed transactions across multiple consensus groups | |
| CN103885854A (en) | Data backup method, data backup device and data backup system | |
| CN114925084B (en) | Distributed transaction processing method, system, equipment and readable storage medium | |
| US20190311054A1 (en) | High throughput order fullfillment database system | |
| CN107533474A (en) | A kind of transaction methods and device | |
| CN110995851A (en) | Message processing method, device, storage medium and equipment | |
| WO2020253045A1 (en) | Configured supplementary processing method and device for data of which forwarding has abnormality, and readable storage medium | |
| US10284649B2 (en) | Distributed processing system | |
| CN105938446B (en) | The data supported based on RDMA and hardware transactional memory replicate fault-tolerance approach | |
| US8521682B2 (en) | Transfer of data from transactional data sources to partitioned databases in restartable environments | |
| CN113742043A (en) | Asynchronous splitting method for server backend task | |
| CN111125240A (en) | Distributed transaction implementation method and device, electronic equipment and storage medium | |
| CN105573867A (en) | Method and system for realizing high availability of MySQL | |
| US10812586B2 (en) | Method and system for high availability topology for master-slave data systems with low write traffic |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| WD01 | Invention patent application deemed withdrawn after publication | ||
| WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20140205 |