CN112765126A - Database transaction management method and device, computer equipment and storage medium - Google Patents
Database transaction management method and device, computer equipment and storage medium Download PDFInfo
- Publication number
- CN112765126A CN112765126A CN202011634397.1A CN202011634397A CN112765126A CN 112765126 A CN112765126 A CN 112765126A CN 202011634397 A CN202011634397 A CN 202011634397A CN 112765126 A CN112765126 A CN 112765126A
- Authority
- CN
- China
- Prior art keywords
- database
- transaction
- identifier
- distributed
- class
- 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
- 238000003860 storage Methods 0.000 title claims abstract description 14
- 238000007726 management method Methods 0.000 title description 16
- 238000000034 method Methods 0.000 claims abstract description 59
- 238000004590 computer program Methods 0.000 claims description 13
- 238000005096 rolling process Methods 0.000 claims description 7
- 230000000903 blocking effect Effects 0.000 abstract description 10
- 238000002360 preparation method Methods 0.000 description 10
- 238000010586 diagram Methods 0.000 description 7
- 238000011084 recovery Methods 0.000 description 5
- 238000004140 cleaning Methods 0.000 description 4
- 238000012423 maintenance Methods 0.000 description 3
- 230000001360 synchronised effect Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 239000000725 suspension Substances 0.000 description 1
Images
Classifications
-
- 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/21—Design, administration or maintenance of databases
-
- 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
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/466—Transaction processing
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Data Mining & Analysis (AREA)
- Computing Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The application relates to a method and a device for managing database transactions, computer equipment and a storage medium. The method comprises the following steps: acquiring a transaction starting request, wherein the transaction starting request comprises a database transaction and a database transaction identifier is distributed to the database transaction; determining a database identifier corresponding to a database which executes preset database operation for the first time in the database transaction as a first-class database identifier; determining a database identifier corresponding to a database which executes preset database operation after the first time in the database transaction as a second-class database identifier; determining the database operation corresponding to the first class of database identification as a single-database transaction to be started, and executing the single-database transaction; and determining the database operation corresponding to the second class database identification as a distributed transaction to be started, and executing the distributed transaction. By adopting the method, the resource occupation and the blocking risk during transaction processing can be reduced when the distributed transaction is processed.
Description
Technical Field
The present application relates to the field of computer technologies, and in particular, to a method and an apparatus for managing database transactions, a computer device, and a storage medium.
Background
A database transaction refers to a database operation sequence that accesses and operates on various data items, and operations in the database operation sequence are either all executed or all not executed, and are an indivisible work unit. Database transactions may be referred to as transactions, which typically include local transactions and distributed transactions. A distributed transaction refers to a transaction that may involve multiple database operations. Traditionally, distributed transactions have been used to process databases. However, the number of cross-library transaction participants involved in the distributed transaction is large, which may cause all cross-library transaction participants to be in a synchronous blocking state in a commit stage after the transaction is executed, and may occupy a large amount of resource space, which may easily cause a blocking risk.
Disclosure of Invention
In view of the foregoing, there is a need to provide a method, an apparatus, a computer device and a storage medium for managing database transactions, which can reduce resource occupation and reduce blocking risk by reducing cross-library transaction participants.
A method of managing database transactions, the method comprising:
acquiring a transaction starting request, wherein the transaction starting request comprises a database transaction and a database transaction identifier is distributed to the database transaction;
determining a database identifier corresponding to a database which executes preset database operation for the first time in the database transaction as a first-class database identifier;
determining a database identifier corresponding to a database which executes preset database operation after the first time in the database transaction as a second-class database identifier;
determining the database operation corresponding to the first class of database identification as a single-database transaction to be started, and executing the single-database transaction;
and determining the database operation corresponding to the second class database identification as a distributed transaction to be started, and executing the distributed transaction.
In one embodiment, the method further comprises:
receiving a transaction submitting request, wherein the transaction submitting request carries the database transaction identifier;
acquiring a database identifier from a database transaction corresponding to the database transaction identifier;
and when the number of the database identifications is single, determining that the database identifications are the first class of database identifications, submitting the single-library transaction corresponding to the database identifications, and ending the single-library transaction.
In one embodiment, the method further comprises:
when the number of the database identifications is multiple, determining a first class database identification and a second class database identification in the database identifications;
recording a commit log of the distributed transaction corresponding to the second type of database identification in a first database corresponding to the first type of database identification;
submitting the submitted log recorded in the first database and the single-database transaction corresponding to the first database for one time;
if the first submission is successful, performing second submission on the distributed transaction corresponding to the second type database identifier;
and if the secondary submission is successful, ending the database transaction corresponding to the database transaction identifier.
In one embodiment, the method further comprises:
if the one-time submission fails, rolling back the distributed transaction corresponding to the second type database identifier;
and if the rollback is successful, ending the database transaction corresponding to the database transaction identifier.
In one embodiment, the method further comprises:
if the rollback fails, performing retry processing on the distributed transaction corresponding to the second type database identifier according to the commit log;
if the retry is successful, ending the database transaction corresponding to the database transaction identifier;
and if the retry fails, suspending the distributed transaction corresponding to the second database identifier and generating alarm information.
In one embodiment, the method further comprises:
if the second submission fails, retry processing is carried out on the distributed transaction corresponding to the second type database identification according to the submission log;
if the retry is successful, ending the database transaction corresponding to the database transaction identifier;
and if the retry fails, suspending the distributed transaction corresponding to the second database identifier and generating alarm information.
In one embodiment, the retrying the distributed transaction corresponding to the second type database identifier according to the commit log includes:
inquiring the database transaction identification in the submission log, and inquiring whether a second-class database identification corresponding to the database transaction identification has uncommitted distributed transactions;
and if so, submitting the uncommitted distributed transaction in a second database corresponding to the corresponding second class database identifier.
In one embodiment, the method further comprises:
when a transaction management server fails, inquiring the suspended distributed transaction, and submitting or rolling back the inquired distributed transaction;
if the execution of the submission or the rollback is successful, the fault is recovered;
and if distributed transactions which fail to execute submission or fail to rollback exist in the inquired distributed transactions, generating alarm information.
In one embodiment, the method further comprises:
and when the database corresponding to the database identifier fails, carrying out retry processing on the distributed transaction corresponding to the second database identifier.
An apparatus for managing database transactions, the apparatus comprising:
the system comprises an acquisition module, a processing module and a processing module, wherein the acquisition module is used for acquiring a transaction starting request, the transaction starting request comprises a database transaction and a database transaction identifier is distributed to the database transaction;
the determining module is used for determining a database identifier corresponding to a database which executes preset database operation for the first time in the database transaction as a first-class database identifier; determining a database identifier corresponding to a database which executes preset database operation after the first time in the database transaction as a second-class database identifier;
the control module is used for determining the database operation corresponding to the first type of database identification as a single-database transaction to be started and executing the single-database transaction; and determining the database operation corresponding to the second class database identification as a distributed transaction to be started, and executing the distributed transaction.
In one embodiment, the apparatus further includes a commit module, configured to receive a transaction commit request, where the transaction commit request carries the database transaction identifier; acquiring a database identifier from a database transaction corresponding to the database transaction identifier; and when the number of the database identifications is single, determining that the database identifications are the first class of database identifications, submitting the single-library transaction corresponding to the database identifications, and ending the single-library transaction.
A computer device comprising a memory and a processor, the memory storing a computer program operable on the processor, the processor implementing the steps in the various method embodiments described above when executing the computer program.
A computer-readable storage medium, on which a computer program is stored which, when being executed by a processor, carries out the steps of the respective method embodiment described above.
The management method, the management device, the computer equipment and the storage medium for the database transactions obtain a transaction start request, wherein the transaction start request comprises the database transactions, database transaction identifiers are distributed to the database transactions, the database identifiers corresponding to the database executing the preset database operation for the first time in the database transactions are determined as first-class database identifiers, the database identifiers corresponding to the database executing the preset database operation for the first time and later in the database transactions are determined as second-class database identifiers, so that the database operation corresponding to the first-class database identifiers is determined as a single-library transaction to be started, the single-library transaction is executed, the database operation corresponding to the second-class database identifiers is determined as a distributed transaction to be started, and the distributed transaction is executed. By opening a single-database transaction for the database which executes the preset database operation for the first time, cross-database transaction parameters are reduced, resource occupation can be reduced, and therefore blocking risks in the transaction execution and subsequent processing processes are reduced.
Drawings
FIG. 1 is a diagram of an application environment for a method of managing database transactions in one embodiment;
FIG. 2 is a flow diagram that illustrates a method for managing database transactions, according to one embodiment;
FIG. 3 is a flow diagram that illustrates the commit step of a transaction in one embodiment;
FIG. 4 is a flowchart showing a transaction commit step in another embodiment;
FIG. 5 is a block diagram showing an example of the structure of a database transaction management apparatus;
FIG. 6 is a diagram illustrating an internal structure of a computer device according to an embodiment.
Detailed Description
In order to make the objects, technical solutions and advantages of the present application more apparent, the present application is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the present application.
The management method of the database transaction provided by the application can be applied to the application environment shown in fig. 1. Wherein the terminal 102 and the transaction management server 104 communicate via a network. The transaction management server may be referred to simply as a server. An application program runs in the terminal 102, the server 104 obtains a transaction start request sent by the application program, the transaction start request includes a database transaction, a database transaction identifier is allocated to the database transaction, a database identifier corresponding to a database executing a preset database operation for the first time in the database transaction is determined as a first type database identifier, a database identifier corresponding to a database executing the preset database operation for the first time and later in the database transaction is determined as a second type database identifier, the database operation corresponding to the first type database identifier is determined as a single database transaction to be started, the single database transaction is executed, the database operation corresponding to the second type database identifier is determined as a distributed transaction to be started, and the distributed transaction is executed. The terminal 102 may be, but is not limited to, various personal computers, notebook computers, smart phones, tablet computers, and portable wearable devices. The server 104 may be implemented as a stand-alone server or as a server cluster comprised of multiple servers.
In one embodiment, as shown in fig. 2, a method for managing database transactions is provided, which is described by taking the method as an example applied to the server in fig. 1, and includes the following steps:
And step 208, determining the database operation corresponding to the first class of database identification as a single-database transaction to be started, and executing the single-database transaction.
And step 210, determining the database operation corresponding to the second class database identifier as a distributed transaction to be started, and executing the distributed transaction.
A transaction refers to a sequence of database operations that access and operate on various data items, consisting of all database operations performed between the beginning of the transaction and the end of the transaction. A transaction may also be referred to as a database transaction. The database transaction identifier is a unique identifier for marking database transactions and is used for distinguishing different database transactions.
The terminal is pre-operated with an application program, and when the application program executes database transaction through the server, the application program can access the database through the server to execute the database transaction. Specifically, the terminal may determine a database transaction to be executed according to an operation instruction of the user on the application program, generate a transaction start request according to the database transaction, and the application program calls an interface of the server to send the transaction start request to the server through the interface. The interface is a uniform transaction interface externally, and the distributed service is started as required in the server. After receiving the transaction starting request, the server analyzes the transaction starting request to obtain the database transaction carried by the transaction starting request. And the server allocates a database transaction identifier to the acquired database transaction and records the state of the database transaction identifier as started. For example, the database transaction identification may be a number of the database transaction.
Since the database transaction includes a database operation on the database, the database transaction may include a database identification of the database. The database identifier refers to a unique identifier for marking the database, and is used for distinguishing different databases. The server determines a database identifier corresponding to a database which needs to execute preset database operation for the first time in the database transaction, and determines the database identifier as a first-class database identifier. The preset database operation may be an SQL (Structured Query Language) statement of an update class, such as insert, delete, and update statements. Therefore, the database identification corresponding to the database which executes the preset database operation after the first time is determined in the database transaction, and the execution after the first time refers to the execution for the second time and then. The preset database operation may be an SQL statement that updates the class. And the server determines the database identifier corresponding to the database which executes the preset database operation for the first time as the second-class database identifier. The second type of database identifier refers to a database identifier corresponding to a database executing the updated SQL-like statement for the first time, that is, when the SQL statement executed by the second and subsequent databases is a non-updated SQL statement, the second type of database identifier is not used.
And the server determines the database operation corresponding to the first class of database identification as a single-database transaction to be started. The database operation can be independently executed by the database corresponding to the first-class database identifier by opening the single-database transaction, the same database transaction is not required to be executed in cooperation with other databases, namely, the distributed transaction is not opened, the execution efficiency of the database transaction can be improved, and the processing cost of the database transaction is reduced.
And the server determines the database operation corresponding to the second class database identification as the distributed transaction to be started. And starting the distributed transaction to enable the databases corresponding to the second class database identifiers to cooperatively execute the distributed transaction, wherein in the executing process, each database corresponding to the second class database identifiers executes corresponding database operation in the distributed transaction. The database operation may be an SQL statement, and the database executes the transaction by executing the SQL statement. For example, the server acquires SQL-1 corresponding to the database DB1, SQL-2 corresponding to the database DB2 and SQL-3 corresponding to the database DB3 in the database transaction, and the server is connected with the database DB1, starts a single-machine transaction and executes SQL-1. The server thus connects to database DB2, opens a distributed transaction (XA transaction) for DB2, and executes SQL-2. The server then connects to database DB3, opens DB3 distributed transaction (XA transaction), executes SQL-3.
In this embodiment, a transaction start request is obtained, where the transaction start request includes a database transaction, a database transaction identifier is allocated to the database transaction, a database identifier corresponding to a database that executes a preset database operation for the first time in the database transaction is determined as a first-class database identifier, a database identifier corresponding to a database that executes the preset database operation for the first time and then in the database transaction is determined as a second-class database identifier, so that a database operation corresponding to the first-class database identifier is determined as a single-library transaction to be started, a single-library transaction is executed, a database operation corresponding to the second-class database identifier is determined as a distributed transaction to be started, and a distributed transaction is executed. By opening a single-database transaction for the database which executes the preset database operation for the first time, cross-database transaction parameters are reduced, resource occupation can be reduced, and therefore blocking risks in the transaction execution and subsequent processing processes are reduced.
In one embodiment, the method further comprises: receiving a transaction submitting request, wherein the transaction submitting request carries a database transaction identifier; acquiring a database identifier from a database transaction corresponding to the database transaction identifier; and when the number of the database identifications is single, determining that the database identifications are the first class of database identifications, submitting the single-library transaction corresponding to the database identifications, and ending the single-library transaction.
The transaction submission refers to writing the modified data of the database into a disk after corresponding database operation is performed on the database according to the database transaction. The transaction commit request is used to instruct the server to commit the transaction. The database transaction identifier refers to a unique identifier used to mark a database transaction.
The terminal is pre-operated with an application program, when the application program executes corresponding database operation on the database through the server, the transaction submission can be carried out, the application program can call an interface of the server, and a transaction submission request is sent to the server through the interface. And after the server receives the transaction submission request, analyzing the transaction submission request to obtain a database transaction identifier carried by the transaction submission request. The database transaction identifier refers to an identifier of a database transaction that needs to be committed, and may be a database transaction number, for example. A database transaction may include various database operations for a database. The database transaction may include database operations of one database or may include database operations of multiple databases. Database transactions may be represented in SQL (Structured Query Language) statements.
Because the database transaction corresponding to the database transaction identifier includes the database operation on the database, the database transaction includes the database identifier of the database. The database identifier refers to a unique identifier for marking the database, and is used for distinguishing different databases. After the server obtains the database transaction identifier, the server can obtain the corresponding database transaction according to the database transaction identifier, so that the database identifier is obtained in the database transaction.
When the number of the database identifications is single, the database transaction only contains the database operation of one database, so that the database identification is the database identification corresponding to the database which executes the preset database operation for the first time, and the server determines that the database identification is the first-class database identification. The database operation corresponding to the first kind of database identification is a single-library transaction, and the server directly submits the single-library transaction corresponding to the database identification. The server can adopt a direct submission mode when submitting the single-library transaction. After the single-library transaction commits, the single-library transaction is ended.
In this embodiment, when the number of the database identifiers is single, it is determined that the database identifiers are the first type of database identifiers, the single-library transaction corresponding to the database identifiers can be directly submitted, the single-library transaction is ended, and the submission efficiency of the database transaction is effectively improved.
In an embodiment, as shown in fig. 3, the method further includes a step of committing the transaction, which may specifically include:
And step 304, acquiring the database identifier from the database transaction corresponding to the database transaction identifier.
And step 306, when the number of the database identifications is single, determining that the database identifications are the first class of database identifications, submitting the single-library transaction corresponding to the database identifications, and ending the single-library transaction.
And step 310, recording a transaction execution log of the distributed transaction corresponding to the second class database identification in the first database corresponding to the first class database identification.
And step 314, if the first submission is successful, performing second submission on the distributed transaction corresponding to the second type database identifier.
After the server obtains the database identifiers, the number of the database identifiers is counted, and when the number of the database identifiers is multiple, it is indicated that the distributed transaction is started, namely the database identifiers include both the first type database identifiers and the second type database identifiers. Wherein a plurality means at least two. The server determines the first class database identification and the second class database identification in the database identifications.
The commit methods for single bank transactions and distributed transactions are different. The server can adopt a direct submission mode when submitting the single-library transaction. After the single-library transaction commits, the single-library transaction is ended. When committing the distributed transaction, the distributed transaction may be implemented by two-phase commit using the database XA-based protocol. The XA protocol is a standard protocol established by the X/Open organization for DTP (Distributed Transaction Processing). Two-phase commit includes a commit preparation phase and a formal commit phase. The commit preparation phase refers to the execution of business logic to determine whether a distributed transaction can commit, and the distributed transaction is not formally committed in this phase.
The server can simultaneously commit the distributed transaction in a commit preparation phase, commit the single-library transaction, and then commit the distributed transaction in a formal phase. Specifically, the server may refer to the database corresponding to the first type of database identifier as a first database, and refer to the database corresponding to the second type of database identifier as a second database. The server can receive a request of a preparation phase of submission sent by the application program, and the server is sequentially connected with the second databases corresponding to the second class database identifiers according to the request of the preparation phase of submission, so that the second databases corresponding to the second class database identifiers execute preparation of submission, and database operation data of distributed transactions executed by the second databases are acquired. After the preparation for submitting the second databases is completed, the server may sequentially record the distributed database operation data executed by each second database in the corresponding transaction execution log in the first database corresponding to the first-class database identifier, so as to obtain a commit log (commit log). Since the server is enabled for distributed transactions on demand, only the transaction execution log of the second database needs to be recorded. The commit log may include the database transaction identification currently executed by the second database and the database identification of each second database. For example, when there are two second databases DB2 and DB3, the resultant commit log may include two lines of data, recording DB2 and DB3, respectively, and the contents of the commit log may include the number of database transactions currently performed by DB2 and DB3, the name of DB2, and the name of DB 3.
The server can make one-time commit for the commit log recorded in the first database and the single-library transaction corresponding to the first database. The submitted single-library transaction corresponding to the first database refers to a database operation executed by the first database, for example, an SQL statement executed on the first database. A commit refers to a commit in the commit preparation phase for a distributed transaction and a commit for a single pool transaction.
If the server successfully submits for one time, the server successfully submits the distributed transaction in a commit preparation phase and submits the single-library transaction. The successful commit of the distributed transactions in the commit preparation phase indicates that each second database can normally commit the distributed transactions, and the successful commit of the single-library transactions indicates that all database operations performed when the single-library transactions are executed on the second databases are successful. At this point, the server may end the single library transaction.
After the first submission is successful, the server can be respectively connected with the second databases, so that each database formally submits the distributed transaction for secondary submission. Performing secondary commit on the distributed transaction means writing modified data obtained after executing the distributed transaction on each database into a disk to ensure that all modifications to the database are committed.
And if the one-time submission fails, the server rolls back the distributed transaction, which indicates that the transaction execution log recorded in the first database does not record the database operation data of the distributed transaction executed by the second database. Rollback refers to canceling a database operation performed when a distributed transaction is executed on a database, and restoring the database to a state before the distributed transaction is executed.
In one embodiment, the method further includes: if one-time submission fails, the distributed transaction corresponding to the second class database identifier is rolled back; if the rollback is successful, the database transaction corresponding to the database transaction identifier is ended.
When the server fails to submit the transaction execution log recorded in the first database and the single-library transaction corresponding to the first database once, the server needs to roll back the distributed transaction corresponding to the second database. If the server successfully rolls back the distributed transaction corresponding to the second database, it indicates that the second database is completely restored to the state before the distributed transaction is executed, and at this time, the server may end the database transaction corresponding to the database transaction identifier. If the rollback of the distributed transaction corresponding to the second database by the server fails, which indicates that the second database cannot be restored to the state before the distributed transaction is executed, the server may retry the distributed transaction corresponding to the second database until the retry is successful. Retry refers to committing uncommitted shares. When all distributed transactions are committed, the retry is successful. At this time, the server ends the database transaction corresponding to the database transaction identifier. After one-time submission failure, the distributed transactions corresponding to the second database identification are rolled back, and the second database can be completely restored to a state between execution of the distributed transactions, so that atomicity and consistency of the distributed transactions are guaranteed. Atomicity means that all data operations contained in a database transaction are either all successful or all failed rollback. Consistency means that a database transaction must transform the database from one consistency state to another, i.e., the database must be in a consistency state both before and after execution of the database transaction.
If the server successfully submits the distributed transactions corresponding to the second-class database identifiers for the second time, the server writes the modified data obtained after the distributed transactions are executed by each second database into the disk, which indicates that all database operations performed when the distributed transactions are executed on the second databases are successful, and at this time, the server can end the database transactions corresponding to the database transaction identifiers, generate a message that the submission is successful, and send the message to the application program. The server can also generate a cleaning task according to the submitted distributed transaction after the second submission is successful, and send the cleaning task to the cleaning server, so that the cleaning server can asynchronously clean the successfully submitted data in the submission log recorded in the first database.
If the server fails to submit the distributed transaction corresponding to the second-class database identifier for the second time, which indicates that the database operations performed when the distributed transaction is executed on the second database are not all successful, the server may retry the distributed transaction corresponding to the second-class database identifier until the retry is successful, and at this time, the server ends the database transaction corresponding to the database transaction identifier.
In one embodiment, the method further includes: if the second submission fails, retry processing is carried out on the distributed transaction corresponding to the second type database identification according to the submission log; if the retry is successful, ending the database transaction corresponding to the database transaction identifier; and if the retry fails, suspending the distributed transaction corresponding to the second class database identifier and generating alarm information.
If the server fails to commit the distributed transaction corresponding to the second type of database identifier for the second time, the server may retry the distributed transaction corresponding to the second type of database identifier according to the commit log recorded in the first database. The uncommitted transaction of the distributed transactions is committed by a retry process. When all distributed transactions are committed, the retry is successful. If the retry is successful, the server ends the database transaction corresponding to the database transaction identifier. If the retry fails, it indicates that the distributed transaction is not committed, the database operation performed on the second database is not completely successful, and the server may suspend the distributed transaction corresponding to the second class database identifier, where the suspension refers to suspending the execution of the distributed transaction corresponding to the second class database identifier. The server can generate alarm information and send the alarm information to the control device so that the control device sends out an alarm prompt, and the alarm mode can be a voice alarm mode, a text alarm mode and other modes. The technician can process the suspended distributed transaction according to the alarm prompt. The automatic recovery of the submission failure can be realized, the blocking risk in the transaction submission process is reduced, and the operation and maintenance cost is reduced.
In one embodiment, when the number of the database identifiers is only one, the server only needs to submit the single-library transaction corresponding to the database identifier, and the single-library transaction is finished after the single-library transaction is submitted. Two-phase commit of the distributed transaction need not be performed. The cost of transaction commit is reduced compared to the way in which database transactions are handled by distributed transactions.
In this embodiment, a transaction commit request is received, the transaction commit request is analyzed, a database transaction identifier carried by the transaction commit request is obtained, the database identifier is obtained from a database transaction corresponding to the database transaction identifier, when the number of the database identifiers is multiple, a first class database identifier corresponding to a single database transaction and a second class database identifier corresponding to a distributed transaction are determined, a transaction execution log of the distributed transaction corresponding to the second class database identifier is recorded in a first database corresponding to the first class database identifier, the transaction execution log recorded in the first database and the single database transaction corresponding to the first database are submitted for one time, if the one-time submission is successful, the distributed transaction corresponding to the second class database identifier is submitted for the second time, and if the two-time submission is successful, the database transaction corresponding to the database transaction identifier is ended. The acquired database identifications comprise first-class database identifications corresponding to the single-library transaction and second-class database identifications corresponding to the distributed transaction, whether the distributed transaction is started can be determined according to the number of the database identifications, the single-library transaction is started for the first database corresponding to the first-class database identifications, cross-library transaction participants are reduced, resource occupation can be reduced when the distributed transaction is submitted for the second time, and therefore the blocking risk when the transaction is submitted is reduced.
In one embodiment, the server submits the submission log recorded in the first database and the single-database transaction corresponding to the first database once, if the one-time submission fails, the distributed transaction corresponding to the second-class database identifier is rolled back, and if the roll-back fails, the distributed transaction corresponding to the second-class database identifier is retried according to the submission log; if the retry is successful, ending the database transaction corresponding to the database transaction identifier; and if the retry fails, suspending the distributed transaction corresponding to the second class database identifier and generating alarm information.
Rollback refers to canceling a database operation performed when a distributed transaction is executed on a database, and restoring the database to a state before the distributed transaction is executed. The retry may be to commit uncommitted shares. Suspending refers to suspending execution of the distributed transaction corresponding to the second class database identification.
If the rollback of the distributed transaction corresponding to the second database by the server fails, which indicates that the second database cannot be restored to the state before the distributed transaction is executed, the server may retry the distributed transaction corresponding to the second database according to the commit log until the retry is successful. When all distributed transactions are committed, the retry is successful. If the retry is successful, the server ends the database transaction corresponding to the database transaction identifier. If the retry fails, it indicates that the distributed transaction is not submitted, the database operation performed on the second database is not completely operated successfully, the server can suspend the distributed transaction corresponding to the second database identifier, and the server can generate alarm information and send the alarm information to the control device, so that the control device sends out an alarm prompt, and the alarm mode can be a voice alarm, a text alarm and other modes. The technician can process the suspended distributed transaction according to the alarm prompt.
In this example, after the rollback failure, by retrying the distributed transaction, the uncommitted distributed transaction can be committed to complete all database operations of the distributed transaction, ensuring the integrity of the transaction. And the automatic recovery of the submission failure can be realized, the blocking risk in the transaction submission process is reduced, and the operation and maintenance cost is reduced. After the retry fails, alarm information is generated, which is beneficial for technicians to process the transaction faults in time.
In one embodiment, retrying the distributed transaction corresponding to the second type database identifier according to the commit log includes: inquiring a database transaction identifier in the commit log, and inquiring whether a second-class database identifier corresponding to the database transaction identifier has an uncommitted distributed transaction; and if so, submitting the uncommitted distributed transaction in a second database corresponding to the corresponding second class database identifier.
In the process of retrying the distributed transaction, the server can inquire a database transaction identifier needing retrying in a commit log through the server, determine a second-class database identifier corresponding to the database transaction identifier and inquire whether the determined second-class database identifier has an uncommitted distributed transaction, if so, the server commits the uncommitted distributed transaction in a second database corresponding to the corresponding second-class database identifier, and after all the uncommitted distributed transactions are committed, the retrying is successful. If the retry is successful, the server ends the database transaction corresponding to the database transaction identifier. Uncommitted distributed transactions can be quickly found to commit.
In one embodiment, the method further comprises: when the transaction management server fails, inquiring the suspended distributed transaction, and submitting or rolling back the inquired distributed transaction; if the execution of the submission or the rollback is successful, the fault is recovered; and if distributed transactions which fail to execute submission or fail to rollback exist in the inquired distributed transactions, generating alarm information.
The transaction management server may be referred to as a server. When a server fails in the transaction submission process, for example, suddenly goes down, the server needs to be restarted, and when the server is started, the distributed transaction which is not submitted and completed before or not rolled back needs to be recovered. Specifically, the server queries the suspended distributed transaction, and when the queried distributed transaction is an uncommitted completed transaction, the server performs commit on the distributed task. And when the inquired distributed transaction is a distributed transaction which is not completed by rollback, the server performs rollback on the distributed transaction. And if all the inquired distributed transactions are submitted or the rollback execution is successful, the transaction is recovered, and the server is started successfully. If the inquired distributed transactions have the transactions which fail to execute submission or fail to execute rollback, the server fails to start and generates alarm information. The server can generate alarm information and send the alarm information to the control device so that the control device sends out an alarm prompt, and the alarm mode can be a voice alarm mode, a text alarm mode and other modes. The technician can process the suspended distributed transaction according to the alarm prompt. When a server fails to associate, the server can be classified as a failure to associate with the database. When the server fails, the automatic recovery of the failure can be carried out, the blocking risk in the transaction submitting process is reduced, and meanwhile, the operation and maintenance cost is reduced.
In one embodiment, the method further includes: and when the database corresponding to the database identifier fails, carrying out retry processing on the distributed transaction corresponding to the second database identifier.
The failure of the database may include a database outage or downtime. When the database corresponding to the database identifier fails in the transaction processing process, the server retries the distributed transaction corresponding to the second database identifier, specifically, the server may query the database transaction identifier that needs to be retried in the commit log, determine the second-class database identifier corresponding to the database transaction identifier, query whether the determined second-class database identifier has an uncommitted distributed transaction, if so, submit the uncommitted distributed transaction in the second database corresponding to the corresponding second-class database identifier, and retry successfully after all the uncommitted distributed transactions are submitted. If the retry is successful, the server ends the database transaction corresponding to the database transaction identifier. And when the database corresponding to the database identifier fails, retry processing can be performed on the distributed transaction corresponding to the second database identifier so as to automatically recover the failure.
In another embodiment, as shown in FIG. 4, the step of transaction committing may further include the steps of:
And step 406, when the number of the database identifiers is single, determining that the database identifiers are the first type of database identifiers, submitting the single-library transaction corresponding to the database identifiers, and ending the single-library transaction.
And step 408, when the number of the database identifications is multiple, determining the first class database identification and the second class database identification in the database identifications.
And step 410, recording a commit log of the distributed transaction corresponding to the second class of database identification in the first database corresponding to the first class of database identification.
And 414, performing secondary submission on the distributed transaction corresponding to the second class database identifier. If the second submission is successful, go to step 418; if the second commit fails, step 420 is performed.
And step 416, rolling back the distributed transaction corresponding to the second class database identifier. If the rollback fails, go to step 422; if the rollback is successful, step 424 is performed.
At step 418, the database transaction identifier is terminated.
And step 420, performing retry processing on the distributed transaction corresponding to the second class database identifier according to the commit log. If the retry is successful, go to step 418; if the retry fails, step 422 is performed.
And step 422, performing retry processing on the distributed transaction corresponding to the second class database identifier according to the commit log. If the retry is successful, go to step 424; if the retry fails, step 426 is performed.
At step 424, the database transaction identifier is terminated.
And 426, suspending the distributed transaction corresponding to the second-class database identifier, and generating alarm information.
It should be understood that although the steps in the flowcharts of fig. 2 to 4 are shown in order as indicated by the arrows, the steps are not necessarily performed in order as indicated by the arrows. The steps are not performed in the exact order shown and described, and may be performed in other orders, unless explicitly stated otherwise. Moreover, at least some of the steps in fig. 2-4 may include multiple sub-steps or multiple stages that are not necessarily performed at the same time, but may be performed at different times, and the order of performing the sub-steps or stages is not necessarily sequential, but may be performed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.
In one embodiment, as shown in fig. 5, there is provided an apparatus for managing database transactions, including: an acquisition module 502, a determination module 504, and a control module 506, wherein:
the obtaining module 502 is configured to obtain a transaction start request, where the transaction start request includes a database transaction and allocates a database transaction identifier for the database transaction.
A determining module 504, configured to determine a database identifier corresponding to a database, which executes a preset database operation for the first time in a database transaction, as a first-class database identifier; and determining a database identifier corresponding to a database which executes preset database operation after the first time in the database transaction as a second-class database identifier.
The control module 506 determines the database operation corresponding to the first type of database identifier as a single-database transaction to be started, and executes the single-database transaction; and determining the database operation corresponding to the second class database identification as a distributed transaction to be started, and executing the distributed transaction.
In one embodiment, the apparatus further includes a commit module, configured to receive a transaction commit request, where the transaction commit request carries a database transaction identifier; acquiring a database identifier from a database transaction corresponding to the database transaction identifier; and when the number of the database identifications is single, determining that the database identifications are the first class of database identifications, submitting the single-library transaction corresponding to the database identifications, and ending the single-library transaction.
In one embodiment, the submitting module is further configured to determine a first class database identifier and a second class database identifier in the database identifiers when the number of the database identifiers is multiple; recording a commit log of a distributed transaction corresponding to the second type of database identification in a first database corresponding to the first type of database identification; submitting the submitted log recorded in the first database and the single database transaction corresponding to the first database for one time; if the first-time submission is successful, performing second-time submission on the distributed transaction corresponding to the second-class database identifier; if the second submission is successful, the database transaction corresponding to the database transaction identifier is ended.
In an embodiment, the apparatus further includes a rollback module, configured to rollback the distributed transaction corresponding to the second class database identifier if one commit fails; if the rollback is successful, the database transaction corresponding to the database transaction identifier is ended.
In an embodiment, the apparatus further includes a retry module, configured to perform retry processing on the distributed transaction corresponding to the second class database identifier according to the commit log if rollback fails; if the retry is successful, ending the database transaction corresponding to the database transaction identifier; and if the retry fails, suspending the distributed transaction corresponding to the second class database identifier and generating alarm information.
In one embodiment, the retry module is further configured to retry the distributed transaction corresponding to the second type database identifier according to the commit log if the second commit fails; if the retry is successful, ending the database transaction corresponding to the database transaction identifier; and if the retry fails, suspending the distributed transaction corresponding to the second class database identifier and generating alarm information.
In one embodiment, the retry module is further configured to query the commit log for a database transaction identifier, and query whether a second class database identifier corresponding to the database transaction identifier exists in an uncommitted distributed transaction; and if so, submitting the uncommitted distributed transaction in a second database corresponding to the corresponding second class database identifier.
In one embodiment, the above apparatus further comprises: the first failure recovery module is used for inquiring the suspended distributed transaction and submitting or rolling back the inquired distributed transaction when the transaction management server fails; if the execution of the submission or the rollback is successful, the fault is recovered; and if distributed transactions which fail to execute submission or fail to rollback exist in the inquired distributed transactions, generating alarm information.
In one embodiment, the above apparatus further comprises: and the second failure recovery module is used for retrying the distributed transaction corresponding to the second database identifier when the database corresponding to the database identifier fails.
For specific limitations of the management device of the database transaction, reference may be made to the above limitations of the management method of the database transaction, which are not described herein again. The modules in the database transaction management device can be wholly or partially implemented by software, hardware and a combination thereof. The modules can be embedded in a hardware form or independent from a processor in the computer device, and can also be stored in a memory in the computer device in a software form, so that the processor can call and execute operations corresponding to the modules.
In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as shown in fig. 6. The computer device includes a processor, a memory, a network interface, and a database connected by a system bus. Wherein the processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device comprises a nonvolatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of an operating system and computer programs in the non-volatile storage medium. The database of the computer device is used for storing data of a management method of database transactions. The network interface of the computer device is used for communicating with an external terminal through a network connection. The computer program is executed by a processor to implement a method of managing database transactions.
Those skilled in the art will appreciate that the architecture shown in fig. 6 is merely a block diagram of some of the structures associated with the disclosed aspects and is not intended to limit the computing devices to which the disclosed aspects apply, as particular computing devices may include more or less components than those shown, or may combine certain components, or have a different arrangement of components.
In one embodiment, a computer device is provided, comprising a memory storing a computer program and a processor implementing the steps of the various embodiments described above when the processor executes the computer program.
In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored, which, when being executed by a processor, carries out the steps of the respective embodiments described above.
It will be understood by those skilled in the art that all or part of the processes of the methods of the embodiments described above can be implemented by hardware instructions of a computer program, which can be stored in a non-volatile computer-readable storage medium, and when executed, can include the processes of the embodiments of the methods described above. Any reference to memory, storage, database, or other medium used in the embodiments provided herein may include non-volatile and/or volatile memory, among others. Non-volatile memory can include read-only memory (ROM), Programmable ROM (PROM), Electrically Programmable ROM (EPROM), Electrically Erasable Programmable ROM (EEPROM), or flash memory. Volatile memory can include Random Access Memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDRSDRAM), Enhanced SDRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), Rambus Direct RAM (RDRAM), direct bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).
The technical features of the above embodiments can be arbitrarily combined, and for the sake of brevity, all possible combinations of the technical features in the above embodiments are not described, but should be considered as the scope of the present specification as long as there is no contradiction between the combinations of the technical features.
The above-mentioned embodiments only express several embodiments of the present application, and the description thereof is more specific and detailed, but not construed as limiting the scope of the invention. It should be noted that, for a person skilled in the art, several variations and modifications can be made without departing from the concept of the present application, which falls within the scope of protection of the present application. Therefore, the protection scope of the present patent shall be subject to the appended claims.
Claims (13)
1. A method for managing database transactions, the method comprising:
acquiring a transaction starting request, wherein the transaction starting request comprises a database transaction and a database transaction identifier is distributed to the database transaction;
determining a database identifier corresponding to a database which executes preset database operation for the first time in the database transaction as a first-class database identifier;
determining a database identifier corresponding to a database which executes preset database operation after the first time in the database transaction as a second-class database identifier;
determining the database operation corresponding to the first class of database identification as a single-database transaction to be started, and executing the single-database transaction;
and determining the database operation corresponding to the second class database identification as a distributed transaction to be started, and executing the distributed transaction.
2. The method of claim 1, further comprising:
receiving a transaction submitting request, wherein the transaction submitting request carries the database transaction identifier;
acquiring a database identifier from a database transaction corresponding to the database transaction identifier;
and when the number of the database identifications is single, determining that the database identifications are the first class of database identifications, submitting the single-library transaction corresponding to the database identifications, and ending the single-library transaction.
3. The method of claim 2, further comprising:
when the number of the database identifications is multiple, determining a first class database identification and a second class database identification in the database identifications;
recording a commit log of the distributed transaction corresponding to the second type of database identification in a first database corresponding to the first type of database identification;
submitting the submitted log recorded in the first database and the single-database transaction corresponding to the first database for one time;
if the first submission is successful, performing second submission on the distributed transaction corresponding to the second type database identifier;
and if the secondary submission is successful, ending the database transaction corresponding to the database transaction identifier.
4. The method of claim 3, further comprising:
if the one-time submission fails, rolling back the distributed transaction corresponding to the second type database identifier;
and if the rollback is successful, ending the database transaction corresponding to the database transaction identifier.
5. The method of claim 3, further comprising:
if the rollback fails, performing retry processing on the distributed transaction corresponding to the second type database identifier according to the commit log;
if the retry is successful, ending the database transaction corresponding to the database transaction identifier;
and if the retry fails, suspending the distributed transaction corresponding to the second database identifier and generating alarm information.
6. The method of claim 3, further comprising:
if the second submission fails, retry processing is carried out on the distributed transaction corresponding to the second type database identification according to the submission log;
if the retry is successful, ending the database transaction corresponding to the database transaction identifier;
and if the retry fails, suspending the distributed transaction corresponding to the second database identifier and generating alarm information.
7. The method according to any one of claims 5 to 6, wherein the retrying the distributed transaction corresponding to the second class database identifier according to the commit log comprises:
inquiring the database transaction identification in the submission log, and inquiring whether a second-class database identification corresponding to the database transaction identification has uncommitted distributed transactions;
and if so, submitting the uncommitted distributed transaction in a second database corresponding to the corresponding second class database identifier.
8. The method of claim 2, further comprising:
when a transaction management server fails, inquiring the suspended distributed transaction, and submitting or rolling back the inquired distributed transaction;
if the execution of the submission or the rollback is successful, the fault is recovered;
and if distributed transactions which fail to execute submission or fail to rollback exist in the inquired distributed transactions, generating alarm information.
9. The method of claim 2, further comprising:
and when the database corresponding to the database identifier fails, carrying out retry processing on the distributed transaction corresponding to the second database identifier.
10. An apparatus for managing database transactions, the apparatus comprising:
the system comprises an acquisition module, a processing module and a processing module, wherein the acquisition module is used for acquiring a transaction starting request, the transaction starting request comprises a database transaction and a database transaction identifier is distributed to the database transaction;
the determining module is used for determining a database identifier corresponding to a database which executes preset database operation for the first time in the database transaction as a first-class database identifier; determining a database identifier corresponding to a database which executes preset database operation after the first time in the database transaction as a second-class database identifier;
the control module is used for determining the database operation corresponding to the first type of database identification as a single-database transaction to be started and executing the single-database transaction; and determining the database operation corresponding to the second class database identification as a distributed transaction to be started, and executing the distributed transaction.
11. The apparatus according to claim 10, further comprising a commit module, configured to receive a transaction commit request, where the transaction commit request carries the database transaction identifier; acquiring a database identifier from a database transaction corresponding to the database transaction identifier; and when the number of the database identifications is single, determining that the database identifications are the first class of database identifications, submitting the single-library transaction corresponding to the database identifications, and ending the single-library transaction.
12. A computer device comprising a memory and a processor, the memory storing a computer program operable on the processor, wherein the processor implements the steps of the method of any one of claims 1 to 9 when executing the computer program.
13. A computer-readable storage medium, on which a computer program is stored, which, when being executed by a processor, carries out the steps of the method of any one of claims 1 to 9.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011634397.1A CN112765126A (en) | 2020-12-31 | 2020-12-31 | Database transaction management method and device, computer equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011634397.1A CN112765126A (en) | 2020-12-31 | 2020-12-31 | Database transaction management method and device, computer equipment and storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112765126A true CN112765126A (en) | 2021-05-07 |
Family
ID=75697896
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011634397.1A Pending CN112765126A (en) | 2020-12-31 | 2020-12-31 | Database transaction management method and device, computer equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112765126A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114003644A (en) * | 2021-10-21 | 2022-02-01 | 河南星环众志信息科技有限公司 | Distributed transaction processing method, device, medium and database system |
Citations (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102306200A (en) * | 2011-09-22 | 2012-01-04 | 用友软件股份有限公司 | Device and method for concurrently applying incremental data manipulation statements |
| CN102306197A (en) * | 2011-09-22 | 2012-01-04 | 用友软件股份有限公司 | Device and method for guaranteeing consistency of data-source-crossing operation results |
| CN102567399A (en) * | 2010-12-31 | 2012-07-11 | 北京新媒传信科技有限公司 | Method and device for accessing database |
| US20130086018A1 (en) * | 2011-09-30 | 2013-04-04 | International Business Machines Corporation | Transaction processing system, method, and program |
| CN103077222A (en) * | 2012-12-31 | 2013-05-01 | 中国科学院计算技术研究所 | Method and system for ensuring consistence of distributed metadata in cluster file system |
| CN103559245A (en) * | 2013-10-29 | 2014-02-05 | 华为技术有限公司 | Distributed transaction committing failure handling method, device and system |
| CN106383737A (en) * | 2016-09-09 | 2017-02-08 | 浪潮软件股份有限公司 | Distributed transaction processing method |
| CN108279986A (en) * | 2017-12-29 | 2018-07-13 | 亿阳安全技术有限公司 | A kind of distributed transaction processing method and device |
| CN108572991A (en) * | 2017-03-14 | 2018-09-25 | 北京京东尚科信息技术有限公司 | Data base processing method, device and storage medium |
| CN108733457A (en) * | 2018-04-12 | 2018-11-02 | 阿里巴巴集团控股有限公司 | The implementation method and device of distributed transaction |
| CN108733589A (en) * | 2018-04-12 | 2018-11-02 | 阿里巴巴集团控股有限公司 | The implementation method and device of distributed transaction heat deployment |
| CN109426552A (en) * | 2017-09-05 | 2019-03-05 | 阿里巴巴集团控股有限公司 | Transaction methods, device and system and electronic equipment |
| CN110347481A (en) * | 2019-07-17 | 2019-10-18 | 北京搜狐新媒体信息技术有限公司 | A kind of method and system for realizing distributed transaction |
| CN111209142A (en) * | 2020-01-02 | 2020-05-29 | 中国平安财产保险股份有限公司 | Cross-database transaction management method, device, equipment and storage medium |
-
2020
- 2020-12-31 CN CN202011634397.1A patent/CN112765126A/en active Pending
Patent Citations (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102567399A (en) * | 2010-12-31 | 2012-07-11 | 北京新媒传信科技有限公司 | Method and device for accessing database |
| CN102306200A (en) * | 2011-09-22 | 2012-01-04 | 用友软件股份有限公司 | Device and method for concurrently applying incremental data manipulation statements |
| CN102306197A (en) * | 2011-09-22 | 2012-01-04 | 用友软件股份有限公司 | Device and method for guaranteeing consistency of data-source-crossing operation results |
| US20130086018A1 (en) * | 2011-09-30 | 2013-04-04 | International Business Machines Corporation | Transaction processing system, method, and program |
| CN103077222A (en) * | 2012-12-31 | 2013-05-01 | 中国科学院计算技术研究所 | Method and system for ensuring consistence of distributed metadata in cluster file system |
| CN103559245A (en) * | 2013-10-29 | 2014-02-05 | 华为技术有限公司 | Distributed transaction committing failure handling method, device and system |
| CN106383737A (en) * | 2016-09-09 | 2017-02-08 | 浪潮软件股份有限公司 | Distributed transaction processing method |
| CN108572991A (en) * | 2017-03-14 | 2018-09-25 | 北京京东尚科信息技术有限公司 | Data base processing method, device and storage medium |
| CN109426552A (en) * | 2017-09-05 | 2019-03-05 | 阿里巴巴集团控股有限公司 | Transaction methods, device and system and electronic equipment |
| CN108279986A (en) * | 2017-12-29 | 2018-07-13 | 亿阳安全技术有限公司 | A kind of distributed transaction processing method and device |
| CN108733457A (en) * | 2018-04-12 | 2018-11-02 | 阿里巴巴集团控股有限公司 | The implementation method and device of distributed transaction |
| CN108733589A (en) * | 2018-04-12 | 2018-11-02 | 阿里巴巴集团控股有限公司 | The implementation method and device of distributed transaction heat deployment |
| CN110347481A (en) * | 2019-07-17 | 2019-10-18 | 北京搜狐新媒体信息技术有限公司 | A kind of method and system for realizing distributed transaction |
| CN111209142A (en) * | 2020-01-02 | 2020-05-29 | 中国平安财产保险股份有限公司 | Cross-database transaction management method, device, equipment and storage medium |
Non-Patent Citations (2)
| Title |
|---|
| MOHAMMAD DASHTI 等: "Transaction Repair for Multi-Version Concurrency Control", 《SIGMOD \'17: PROCEEDINGS OF THE 2017 ACM INTERNATIONAL CONFERENCE ON MANAGEMENT OF DATA》, 9 May 2017 (2017-05-09), pages 235, XP058880912, DOI: 10.1145/3035918.3035919 * |
| 周智: "基于Mycat的分布式数据库在运营商IT系统转型中的实现与探索", 《电脑知识与技术》, vol. 14, no. 15, 25 May 2018 (2018-05-25), pages 25 - 27 * |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114003644A (en) * | 2021-10-21 | 2022-02-01 | 河南星环众志信息科技有限公司 | Distributed transaction processing method, device, medium and database system |
| CN114003644B (en) * | 2021-10-21 | 2022-11-15 | 河南星环众志信息科技有限公司 | Distributed transaction processing method, device, medium and database system |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9779128B2 (en) | System and method for massively parallel processing database | |
| US8868577B2 (en) | Generic database manipulator | |
| EP1062569B1 (en) | Isolation levels and compensating transactions in an information system | |
| EP2825958B1 (en) | Systems and methods for supporting transaction recovery based on a strict ordering of two-phase commit calls | |
| JPS633341B2 (en) | ||
| WO2013138770A1 (en) | Systems and methods for supporting inline delegation of middle-tier transaction logs to database | |
| JP2005025432A (en) | Transaction processing method, transaction controller, and transaction control program | |
| CN111522631A (en) | Distributed transaction processing method, device, server and medium | |
| US6944635B2 (en) | Method for file deletion and recovery against system failures in database management system | |
| CN110727698A (en) | Database access method and device, computer equipment and storage medium | |
| CN107533474A (en) | A kind of transaction methods and device | |
| CN111210350A (en) | Block chain transaction method and device, computer equipment and storage medium | |
| US11061889B2 (en) | Systems and methods of managing manifest refresh in a database | |
| CN112765126A (en) | Database transaction management method and device, computer equipment and storage medium | |
| CN112711606A (en) | Database access method and device, computer equipment and storage medium | |
| WO2023111910A1 (en) | Rolling back database transaction | |
| CN114756408A (en) | Metadata backup recovery method and device, electronic equipment and storage medium | |
| US11301341B2 (en) | Replication system takeover with handshake | |
| JPH0561748A (en) | System for automating synchronous confirmation in database access | |
| CN109522098A (en) | Transaction methods, device, system and storage medium in distributed data base | |
| CN113625825B (en) | Method for realizing transactional memory based on thread logic clock | |
| US20220382635A1 (en) | Method and apparatus for processing transaction | |
| CN117234670A (en) | Distributed transaction processing method, system, computer equipment and storage medium | |
| JP2000315190A (en) | Job recovery system | |
| CN112487081A (en) | Data synchronization method, device, storage medium and equipment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |