CN112765126B - Database transaction management method, device, computer equipment and storage medium - Google Patents

Database transaction management method, device, computer equipment and storage medium Download PDF

Info

Publication number
CN112765126B
CN112765126B CN202011634397.1A CN202011634397A CN112765126B CN 112765126 B CN112765126 B CN 112765126B CN 202011634397 A CN202011634397 A CN 202011634397A CN 112765126 B CN112765126 B CN 112765126B
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.)
Active
Application number
CN202011634397.1A
Other languages
Chinese (zh)
Other versions
CN112765126A (en
Inventor
林志贤
郑政芳
胡海明
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Kingdee Software China Co Ltd
Original Assignee
Kingdee Software China Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Kingdee Software China Co Ltd filed Critical Kingdee Software China Co Ltd
Priority to CN202011634397.1A priority Critical patent/CN112765126B/en
Publication of CN112765126A publication Critical patent/CN112765126A/en
Application granted granted Critical
Publication of CN112765126B publication Critical patent/CN112765126B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

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 database transaction management method, a database transaction management device, 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 distributing a database transaction identifier for the database transaction; determining a database identifier corresponding to a database for executing preset database operation for the first time in the database transaction as a first type of 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 type database identifier 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 identifier as a distributed transaction to be started, and executing the distributed transaction. By adopting the method, the occupation of resources and the blocking risk during transaction processing can be reduced when the distributed transaction is processed.

Description

Database transaction management method, device, computer equipment and storage medium
Technical Field
The present application relates to the field of computer technologies, and in particular, to a method and apparatus for managing database transactions, a computer device, and a storage medium.
Background
A database transaction refers to a sequence of database operations that access and operate on various data items, with the operations in the sequence of database operations being either all performed or none performed, being an indivisible unit of work. Database transactions may be referred to as transactions, which generally include local transactions and distributed transactions. Distributed transactions refer to a transaction that may involve multiple database operations. Traditionally, databases have been handled with distributed transactions. However, the number of the cross-library transaction participants involved in the distributed transaction is large, so that all the cross-library transaction participants are in a synchronous blocking state in the commit stage after the transaction is executed, and occupy a large amount of resource space, and thus blocking risks are easily caused.
Disclosure of Invention
In view of the foregoing, it is desirable to provide a method, apparatus, computer device, and storage medium for managing database transactions that can reduce resource occupation and reduce blocking risk by reducing cross-database 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 distributing a database transaction identifier for the database transaction;
Determining a database identifier corresponding to a database for executing preset database operation for the first time in the database transaction as a first type of 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 type database identifier 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 identifier as a distributed transaction to be started, and executing the distributed transaction.
In one embodiment, the method further comprises:
receiving a transaction commit request, wherein 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 identifiers is single, determining that the database identifiers are the first type of database identifiers, submitting single-database transactions corresponding to the database identifiers, and ending the single-database transactions.
In one embodiment, the method further comprises:
when the number of the database identifiers is a plurality of, determining a first type database identifier and a second type database identifier in the database identifiers;
Recording a commit log of the distributed transaction corresponding to the second class database identifier in a first database corresponding to the first class database identifier;
Submitting the commit log recorded in the first database and the single-database transaction corresponding to the first database once;
If the primary submission is successful, performing secondary submission on the distributed transaction corresponding to the second class database identifier;
and ending the database transaction corresponding to the database transaction identifier if the secondary submission is successful.
In one embodiment, the method further comprises:
If the one-time submission fails, rollback is carried out on the distributed transaction corresponding to the second class 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, retrying the distributed transaction corresponding to the second class 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 class database identifier to generate alarm information.
In one embodiment, the method further comprises:
If the secondary submission fails, retrying the distributed transaction corresponding to the second class database identifier 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 to generate alarm information.
In one embodiment, the retrying the distributed transaction corresponding to the second class database identifier according to the commit log includes:
Querying the database transaction identifier in the submitted log, and querying whether a second class database identifier corresponding to the database transaction identifier has an uncommitted distributed transaction or not;
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:
Querying a suspended distributed transaction when a transaction management server fails, and executing submission or rollback on the queried distributed transaction;
if the execution commit or rollback is successful, recovering from the fault;
And if the queried distributed transaction has the distributed transaction with the execution submission failure or the rollback failure, generating alarm information.
In one embodiment, the method further comprises:
and when the database corresponding to the database identifier fails, retrying the distributed transaction corresponding to the second database identifier.
A database transaction management apparatus, the apparatus comprising:
The system comprises an acquisition module, a transaction starting module and a transaction 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 for the database transaction;
The determining module is used for determining a database identifier corresponding to a database for executing preset database operation for the first time in the database transaction as a first type of 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 determines the database operation corresponding to the first type 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 identifier 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, the transaction commit request carrying 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 identifiers is single, determining that the database identifiers are the first type of database identifiers, submitting single-database transactions corresponding to the database identifiers, and ending the single-database transactions.
A computer device comprising a memory storing a computer program executable on the processor and a processor implementing the steps of the method embodiments described above when the computer program is executed by the processor.
A computer readable storage medium having stored thereon a computer program which when executed by a processor performs the steps of the various method embodiments described above.
The method, the device, the computer equipment and the storage medium for managing the database transaction acquire a transaction starting request, wherein the transaction starting request comprises a database transaction, a database transaction identifier is allocated to the database transaction, a database identifier corresponding to a database which executes preset database operations for the first time in the database transaction is determined to be a first type of database identifier, a database identifier corresponding to a database which executes the preset database operations after the first time in the database transaction is determined to be a second type of database identifier, so that the database operations corresponding to the first type of database identifier are determined to be opened as a single database transaction, the single database transaction is executed, the database operations corresponding to the second type of database identifiers are determined to be opened as a distributed transaction, and the distributed transaction is executed. By opening a single database transaction for a database which performs preset database operation for the first time, cross-database transaction parameters are reduced, and resource occupation can be reduced, so that blocking risks in transaction execution and subsequent processing processes are reduced.
Drawings
FIG. 1 is an application environment diagram of a method of managing database transactions in one embodiment;
FIG. 2 is a flow diagram of a method of managing database transactions in one embodiment;
FIG. 3 is a flow diagram of a transaction commit step in one embodiment;
FIG. 4 is a flow chart of a transaction commit step in another embodiment;
FIG. 5 is a block diagram of an apparatus for managing database transactions in one embodiment;
Fig. 6 is an internal structural diagram of a computer device in one embodiment.
Detailed Description
The present application will be described in further detail with reference to the drawings and examples, in order to make the objects, technical solutions and advantages of the present application more apparent. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the scope of the application.
The method for managing database transactions provided by the application can be applied to an application environment shown in figure 1. Wherein the terminal 102 communicates with the transaction management server 104 via a network. The transaction management server may be simply referred to as a server. The terminal 102 is running with an application program, 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 for which a preset database operation is first executed in the database transaction is determined to be a first type of database identifier, a database identifier corresponding to a database for which a preset database operation is first executed in the database transaction is determined to be a second type of database identifier, a database operation corresponding to the first type of database identifier is determined to be a single database transaction to be started, a single database transaction is executed, a database operation corresponding to the second type of database identifier is determined to be a distributed transaction to be started, and a 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, among others. The server 104 may be implemented as a stand-alone server or as a server cluster of multiple servers.
In one embodiment, as shown in fig. 2, a method for managing database transactions is provided, and the method is applied to the server in fig. 1 for illustration, and includes the following steps:
Step 202, a transaction initiation request is obtained, the transaction initiation request including a database transaction, and a database transaction identifier is assigned to the database transaction.
Step 204, determining a database identifier corresponding to a database for which a preset database operation is first executed in the database transaction as a first type of database identifier.
And 206, determining the database identifier corresponding to the database which executes the preset database operation after the first time in the database transaction as the second class database identifier.
And step 208, determining the database operation corresponding to the first type database identifier as a single-database transaction to be started, and executing the single-database transaction.
And 210, determining the database operation corresponding to the second class database identifier as the 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. Database transaction identification refers to a unique identification used to tag database transactions for distinguishing between different database transactions.
The terminal is pre-run with an application program, and when the application program executes the 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, call an interface of the server by the application program, and send the transaction start request to the server through the interface. The interface is a unified transaction interface, 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 a database transaction carried by the transaction starting request. 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 the 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 is a unique identifier of the index database and is used to distinguish between 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 type of database identifier. The preset database operation may be an update-like SQL (Structured Query Language ) statement, for example, insert, delete, update statement. Thus, the database identification corresponding to the database for executing the preset database operation after the first time is determined in the database transaction, and the first time after execution refers to the second time and later execution. The preset database operation may be an SQL statement of the update class. And the server determines the database identifier corresponding to the database which executes the preset database operation after the first time as the second class database identifier. The second type database identifier refers to a database identifier corresponding to a database for executing the update type SQL statement after the first time, that is, when the SQL statement executed by the second and subsequent databases is a non-update type SQL statement, the second type database identifier is not used.
And the server determines the database operation corresponding to the first type database identifier as a single-database transaction to be started. By opening the single-database transaction, the database corresponding to the first-type database identifier can independently execute the database operation, and the same database transaction is not required to be executed in cooperation with other databases, namely, the distributed transaction cannot be opened, so that 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 identifier as the distributed transaction to be started. And enabling the databases corresponding to the second class database identifiers to cooperatively execute the distributed transaction by opening the distributed transaction, wherein in the execution process, each database corresponding to the second class database identifiers executes the corresponding database operation in the distributed transaction. The database operation may be an SQL statement, and the database performs the transaction by executing the SQL statement. For example, the server acquires that the database transaction comprises SQL-1 corresponding to the database DB1, SQL-2 corresponding to the database DB2 and SQL-3 corresponding to the database DB3, and the server is connected with the database DB1 to start a single-machine transaction and execute the SQL-1. The server thus interfaces with database DB2, opens a distributed transaction (XA transaction) of DB2, executing SQL-2. The server is connected with the database DB3 again, opens the distributed transaction (XA transaction) of the DB3, and 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 in which a preset database operation is first executed in the database transaction is determined to be a first type of database identifier, a database identifier corresponding to a database in which a preset database operation is first executed after the first time in the database transaction is determined to be a second type of database identifier, so that a database operation corresponding to the first type of database identifier is determined to be a single database transaction to be started, the single database transaction is executed, a database operation corresponding to the second type of database identifier is determined to be a distributed transaction to be started, and the distributed transaction is executed. By opening a single database transaction for a database which performs preset database operation for the first time, cross-database transaction parameters are reduced, and resource occupation can be reduced, so that blocking risks in 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; when the number of the database identifiers is single, determining the database identifiers as the first type of database identifiers, submitting single-database transactions corresponding to the database identifiers, and ending the single-database transactions.
The transaction submitting refers to writing the data modified by the database into a disk after corresponding database operation is carried out on the database according to the database transaction. The transaction commit request is used to instruct the server to commit the transaction. Database transaction identification refers to a unique identification used to tag database transactions.
The terminal is pre-operated with an application program, when the application program executes corresponding database operation on the database through the server, the application program can submit the transaction, and the application program can call an interface of the server and send a transaction submitting request to the server through the interface. After receiving the transaction submitting request, the server analyzes the transaction submitting request to obtain a database transaction identifier carried by the transaction submitting request. Database transaction identification refers to an identification of a database transaction that needs to be committed, and may be, for example, a database transaction number. Database transactions may include various database operations for a database. Database transactions may include database operations for one database or database operations for multiple databases. Database transactions may be represented by SQL (Structured Query Language ) statements.
Because the database transaction corresponding to the database transaction identifier comprises the database operation on the database, the database transaction comprises the database identifier of the database. The database identifier is a unique identifier of the index database and is used to distinguish between different databases. After the server obtains the database transaction identifier, the server can obtain the corresponding database transaction according to the database transaction identifier, thereby obtaining the database identifier in the database transaction.
When the number of the database identifiers is single, the database operation of only one database is indicated in the database transaction, so that the database identifier is the database identifier corresponding to the database for which the preset database operation is executed for the first time, and the server determines that the database identifier is the first type of database identifier. The database corresponding to the first type of database identifier is operated as a single-database transaction, and the server directly submits the single-database transaction corresponding to the database identifier. The server may take the form of a direct commit when committing a single library transaction. After the single library transaction commits, the single library transaction is ended.
In this embodiment, when the number of database identifiers is single, it is determined that the database identifiers are the first type of database identifiers, so that single-database transactions corresponding to the database identifiers can be directly submitted, and the single-database transactions are ended, thereby effectively improving the efficiency of submitting the database transactions.
In one embodiment, as shown in fig. 3, the method further includes a step of transaction commit, which specifically may include:
in step 302, a transaction commit request is received, the transaction commit request carrying a database transaction identification.
Step 304, the database identifier is obtained from the database transaction corresponding to the database transaction identifier.
And 306, when the number of the database identifiers is single, determining that the database identifiers are the first type of database identifiers, submitting single-database transactions corresponding to the database identifiers, and ending the single-database transactions.
In step 308, when the number of database identifiers is plural, a first type database identifier and a second type database identifier in the database identifiers are determined.
In step 310, a transaction execution log of the distributed transaction corresponding to the second class database identifier is recorded in the first database corresponding to the first class database identifier.
And step 312, the transaction execution log recorded in the first database and the single-database transaction corresponding to the first database are submitted once.
And step 314, if the primary commit is successful, performing secondary commit on the distributed transaction corresponding to the second class database identifier.
And step 316, if the secondary commit is successful, ending the database transaction corresponding to the database transaction identifier.
After the server acquires the database identifiers, counting the number of the database identifiers, and when the number of the database identifiers is a plurality of, indicating that the distributed transaction is started, wherein the database identifiers comprise the first type database identifiers and the second type database identifiers. Wherein, a plurality refers to at least two. The server determines a first type of database identifier and a second type of database identifier in the database identifiers.
The commit methods of single library transactions and distributed transactions are different. The server may take the form of a direct commit when committing a single library transaction. After the single library transaction commits, the single library transaction is ended. When submitting a distributed transaction, the distributed transaction may be implemented by two-phase commit using a database XA-based protocol. The XA protocol is a standard protocol formulated by the X/Open organization for DTP (Distributed Transaction Processing, distributed transaction). The two-phase commit includes a commit preparation phase and a formal commit phase. The commit preparation phase refers to executing business logic to determine whether a distributed transaction can commit, at which stage the distributed transaction is not formally committed.
The server can simultaneously commit the distributed transaction in the commit preparation stage, commit the single-library transaction, and then commit the distributed transaction in the formal stage. Specifically, the server may refer to a database corresponding to the first type of database identifier as a first database, and refer to a database corresponding to the second type of database identifier as a second database. The server can receive a request of a submitting preparation stage sent by the application program, and the server is connected with the second databases corresponding to the second class database identifiers in sequence according to the request of the submitting preparation stage, so that the second databases corresponding to the second class database identifiers execute submitting preparation, and database operation data of the distributed transaction executed by the second databases are obtained. After the preparation for submitting the second databases is completed, the server may record, in the first databases corresponding to the first type database identifiers, the distributed database operation data executed by each second database in the corresponding transaction execution log in turn, so as to obtain a commit log (commitLog). Since the server is on-demand to enable distributed transactions, only the transaction execution log of the second database needs to be recorded. The commit log may include an identification of database transactions currently being performed by the second databases and an identification of the database of each second database. For example, when there are two second databases DB2 and DB3, two lines of data may be included in the resulting commit log, DB2 and DB3 are recorded, respectively, and the contents of the commit log may include the database transaction number, DB2 name, and DB3 name currently being executed by DB2 and DB 3.
The server can commit the commit log recorded in the first database and the single-database transaction corresponding to the first database once. The single-database transaction corresponding to the submitted first database refers to a database operation performed by the first database, for example, an SQL statement performed on the first database. One commit refers to the commit of the commit preparation phase for the distributed transaction, as well as the commit for the single library transaction.
If the server succeeds in one commit, the server succeeds in commit preparation phase commit for the distributed transaction and commit for the single library transaction. The successful commit of the commit preparation phase for the distributed transaction indicates that each second database can normally commit the distributed transaction, and the successful commit for the single-database transaction indicates that all database operations performed when the single-database transaction was performed on the second database have been successful. At this point, the server may end the single library transaction.
After the primary submission is successful, the server can be connected with the second database respectively, so that each database formally submits the distributed transaction to carry out secondary submission. The second commit of the distributed transaction refers to writing the modified data obtained after the distributed transaction is performed by each database to disk to ensure that the modifications to the databases are all committed.
If one commit fails, indicating that the database operation data of the second database for executing the distributed transaction is not recorded in the transaction execution log recorded in the first database, the server rolls back the distributed transaction. Rollback refers to canceling a database operation performed when executing a distributed transaction on a database, and restoring the database to a state prior to executing the distributed transaction.
In one embodiment, the method further comprises: if the one-time submission fails, rollback is carried out on the distributed transaction corresponding to the second class database identifier; and if the rollback is successful, ending the database transaction corresponding to the database transaction identifier.
When the server fails to commit the transaction execution log recorded in the first database and the single-database transaction corresponding to the first database once, the server needs to rollback the distributed transaction corresponding to the second database. If the server rolls back the distributed transaction corresponding to the second database successfully, the state that the second database is fully restored to the state before the distributed transaction is executed is indicated, and at this time, the server can end the database transaction corresponding to the database transaction identifier. If the server fails to rollback the distributed transaction corresponding to the second database, which indicates that the second database cannot be restored to the state before the distributed transaction is executed, the server can retry the distributed transaction corresponding to the second database until the retry is successful. Retry refers to committing the uncommitted distributed. When all distributed transactions are committed, a retry is indicated as successful. At this time, the server ends the database transaction corresponding to the database transaction identifier. After one commit failure, rollback is performed on the distributed transaction corresponding to the identifier of the second class database, and the second database can be completely restored to a state between executing the distributed transactions, so that the atomicity and consistency of the distributed transactions are ensured. Atomicity is the rolling back of all data operations contained in a database transaction, either all successful or all failed. Coherency is where a database transaction must cause the database to transition from a previous coherency state to another coherency state, i.e., the database must be in a coherency state both before and after execution of the database transaction.
If the server successfully submits the distributed transaction corresponding to the second type database identifier for the second time, the server writes the modified data obtained after each second database executes the distributed transaction into a disk, which indicates that all database operations performed when the distributed transaction is executed on the second database are successful, at this time, the server can end the database transaction corresponding to the database transaction identifier, generate a successful commit message, and send the successful commit message to the application program. The server can also generate a cleaning task according to the submitted distributed transaction after the secondary submission is successful, and send the cleaning task to the cleaning server so that the cleaning server can asynchronously clean the submitted successful data in the submitted log recorded in the first database.
If the server fails to secondarily submit the distributed transaction corresponding to the second type database identifier, which indicates that all database operations performed when the distributed transaction is executed on the second database are not successful, the server can retry the distributed transaction corresponding to the second type 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 comprises: if the secondary submission fails, retrying the distributed transaction corresponding to the second class database identifier according to the submission log; if the retry is successful, ending the database transaction corresponding to the database transaction identifier; if the retry fails, suspending the distributed transaction corresponding to the second class database identifier, and generating alarm information.
If the server fails to secondarily submit the distributed transaction corresponding to the second class database identifier, the server can retry the distributed transaction corresponding to the second class database identifier according to the submit log recorded in the first database. And submitting the uncommitted transactions in the distributed transactions through retry processing. When all distributed transactions are committed, a retry is indicated as successful. If the retry is successful, the server ends the database transaction corresponding to the database transaction identifier. If the retry fails, indicating that the distributed transaction is not submitted to completion, and the database operation performed on the second database is not successful in the incomplete operation, the server may suspend the distributed transaction corresponding to the second type database identifier, where suspending refers to suspending the execution of the distributed transaction corresponding to the second type database identifier. The server can generate alarm information and send the alarm information to the control device so that the control device can send out alarm prompts, and the alarm modes can be various modes such as voice alarm, text alarm and the like. The technician can process the suspended distributed transaction accordingly according to the alarm prompt. The method can realize automatic recovery of the submitting faults, reduce the blocking risk in the transaction submitting process and reduce the operation and maintenance cost.
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 ended after the submission is completed. There is no need to conduct two-phase commit of the distributed transaction. The cost of transaction commit is reduced compared to a manner in which distributed transactions are employed to process database transactions.
In this embodiment, a transaction commit request is received, a transaction commit request is parsed to obtain a carried database transaction identifier, a database identifier is obtained in database transactions corresponding to the database transaction identifier, when the number of database identifiers is multiple, a first type database identifier corresponding to a single database transaction and a second type database identifier corresponding to a distributed transaction are determined, a transaction execution log of the distributed transaction corresponding to the second type database identifier is recorded in a first database corresponding to the first type database identifier, the transaction execution log recorded in the first database and the single database transaction corresponding to the first database are submitted once, if the first commit is successful, the distributed transaction corresponding to the second type database identifier is submitted secondarily, and if the second commit is successful, the database transaction corresponding to the database transaction identifier is ended. Because the obtained plurality of database identifiers comprise the first type database identifiers corresponding to the single-database transaction and the second type database identifiers corresponding to the distributed transaction, whether to start the distributed transaction can be determined according to the number of the database identifiers, and the single-database transaction is started for the first database corresponding to the first type database identifiers, so that cross-database transaction participants are reduced, and the resource occupation can be reduced when the distributed transaction is submitted for the second time, so that the blocking risk when the transaction is submitted is reduced.
In one embodiment, the server submits the commit log recorded in the first database and the single-database transaction corresponding to the first database once, rolls back the distributed transaction corresponding to the second-type database identifier if the single-database transaction fails, and retries the distributed transaction corresponding to the second-type database identifier according to the commit log if the rolling back fails; if the retry is successful, ending the database transaction corresponding to the database transaction identifier; 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 executing a distributed transaction on a database, and restoring the database to a state prior to executing the distributed transaction. Retry may be to commit the uncommitted distributed. Suspending refers to suspending execution of the distributed transaction corresponding to the second class database identifier.
If the server fails to rollback the distributed transaction corresponding to the second database, which indicates that the second database cannot be restored to the state before executing the distributed transaction, 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, a retry is indicated as successful. If the retry is successful, the server ends the database transaction corresponding to the database transaction identifier. If the retry fails, the distributed transaction is not submitted, the database operation on the second database is not successful, the server can suspend the distributed transaction corresponding to the second class 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 modes can be various modes such as voice alarm, text alarm and the like. The technician can process the suspended distributed transaction accordingly 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 submitting faults can be realized, the blocking risk in the transaction submitting process is reduced, and the operation and maintenance cost is reduced. After the retry fails, alarm information is generated, so that the technical staff can process the transaction faults in time.
In one embodiment, retrying the distributed transaction corresponding to the second class database identifier according to the commit log includes: inquiring a database transaction identifier in the submitted log, and inquiring whether an uncommitted distributed transaction exists in a second class database identifier corresponding to the database transaction identifier; if so, submitting the uncommitted distributed transaction in a second database corresponding to the corresponding second class database identifier.
In the process of retrying distributed transactions, the server can inquire a database transaction identifier which needs to be retried in a commit log through the server, determine a second type database identifier corresponding to the database transaction identifier, inquire whether the uncommitted distributed transactions exist in the determined second type database identifier, commit the uncommitted distributed transactions in a second database corresponding to the corresponding second type database identifier if the uncommitted distributed transactions exist, and retry is successful after all the uncommitted distributed transactions are committed. If the retry is successful, the server ends the database transaction corresponding to the database transaction identifier. Uncommitted distributed transactions can be quickly found for commit.
In one embodiment, the method further comprises: querying the suspended distributed transaction when the transaction management server fails, and executing submission or rollback on the queried distributed transaction; if the execution commit or rollback is successful, recovering from the fault; and if the queried distributed transaction has the distributed transaction with the execution commit failure or rollback failure, generating alarm information.
The transaction management server may be referred to as a server. When a server fails during the transaction commit process, such as suddenly crashes, the server needs to be restarted, and when the server starts, the server needs to reply to a distributed transaction that was not committed to completion before or was not rolled back to completion. 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. When the queried distributed transaction is a distributed transaction which is not completed by rollback, the server executes rollback on the distributed transaction. If all queried distributed transactions are submitted or rolled back successfully, the transaction is recovered, and the server is started successfully. If the queried distributed transaction has the transaction with the execution commit failure or the execution rollback failure, the server is started to fail, and alarm information is generated. The server can generate alarm information and send the alarm information to the control device so that the control device can send out alarm prompts, and the alarm modes can be various modes such as voice alarm, text alarm and the like. The technician can process the suspended distributed transaction accordingly according to the alarm prompt. When a server fails out of connection, the server may be categorized as a database failure out of connection. When the server fails, the failure can be automatically recovered, so that the blocking risk in the process of submitting the transaction is reduced, and the operation and maintenance cost is reduced.
In one embodiment, the method further comprises: and when the database corresponding to the database identifier fails, retrying the distributed transaction corresponding to the second database identifier.
Database failures may include database outages or outages. 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 can inquire the database transaction identifier needing to be retried in the commit log, determine the second type database identifier corresponding to the database transaction identifier, inquire whether the uncommitted distributed transaction exists in the determined second type database identifier, if so, the server commits the uncommitted distributed transaction in the second database corresponding to the corresponding second type database identifier, and after all the uncommitted 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. 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 from the failure.
In another embodiment, as shown in FIG. 4, the step of transaction commit may further include the steps of:
in step 402, a transaction commit request is received, the transaction commit request carrying a database transaction identification.
Step 404, obtaining the database identifier in the database transaction corresponding to the database transaction identifier.
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 single-database transactions corresponding to the database identifiers, and ending the single-database transactions.
In step 408, when the number of database identifiers is plural, a first type database identifier and a second type database identifier in the database identifiers are determined.
In step 410, a commit log of the distributed transaction corresponding to the second class database identifier is recorded in the first database corresponding to the first class database identifier.
Step 412, performing one-time commit on the commit log recorded in the first database and the single-library transaction corresponding to the first database; if the first submission is successful, go to step 414; if a commit fails, step 416 is performed.
And step 414, performing secondary submission on the distributed transaction corresponding to the second class database identifier. If the second commit is successful, go to step 418; if the secondary 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.
And 418, ending the database transaction corresponding to the database transaction identifier.
And step 420, retrying 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.
Step 422, retrying 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.
And step 424, ending the database transaction corresponding to the database transaction identifier.
And step 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, these steps are not necessarily performed in order as indicated by the arrows. The steps are not strictly limited to the order of execution unless explicitly recited herein, and the steps may be executed in other orders. Moreover, at least some of the steps in fig. 2-4 may include multiple sub-steps or stages that are not necessarily performed at the same time, but may be performed at different times, nor does the order in which the sub-steps or stages are performed necessarily occur in sequence, but may be performed alternately or alternately with at least a portion of the sub-steps or stages of other steps or other steps.
In one embodiment, as shown in fig. 5, there is provided a management apparatus for database transactions, including: an acquisition module 502, a determination module 504, and a control module 506, wherein:
the acquiring module 502 is configured to acquire a transaction initiation request, where the transaction initiation request includes a database transaction, and allocate a database transaction identifier to the database transaction.
A determining module 504, configured to determine a database identifier corresponding to a database in the database transaction that performs a preset database operation for the first time as a first type of database identifier; and determining the database identifier corresponding to the database which executes the 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 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 identifier as the 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, the transaction commit request carrying a database transaction identifier; acquiring a database identifier from a database transaction corresponding to the database transaction identifier; when the number of the database identifiers is single, determining the database identifiers as the first type of database identifiers, submitting single-database transactions corresponding to the database identifiers, and ending the single-database transactions.
In one embodiment, the submitting module is further configured to determine a first type of database identifier and a second type of database identifier in the database identifiers when the number of database identifiers is plural; recording a commit log of the distributed transaction corresponding to the second class database identifier in a first database corresponding to the first class database identifier; submitting the commit log recorded in the first database and the single-database transaction corresponding to the first database once; if the first submission is successful, the distributed transaction corresponding to the second class database identifier is submitted for the second time; and if the secondary submission is successful, ending the database transaction corresponding to the database transaction identifier.
In one 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; and if the rollback is successful, ending the database transaction corresponding to the database transaction identifier.
In one embodiment, the device further includes a retry module, configured to retry, if the rollback fails, the distributed transaction corresponding to the identifier of the second class database according to the commit log; if the retry is successful, ending the database transaction corresponding to the database transaction identifier; 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 identifier of the second class database 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; 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 an uncommitted distributed transaction exists in a second class of database identifiers corresponding to the database transaction identifier; if so, submitting the uncommitted distributed transaction in a second database corresponding to the corresponding second class database identifier.
In one embodiment, the apparatus further comprises: the first fault recovery module is used for inquiring the suspended distributed transaction when the transaction management server fails and executing submission or rollback on the inquired distributed transaction; if the execution commit or rollback is successful, recovering from the fault; and if the queried distributed transaction has the distributed transaction with the execution commit failure or rollback failure, generating alarm information.
In one embodiment, the apparatus further comprises: and the second fault 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 regarding the management of database transactions, reference may be made to the above limitation of the management method of database transactions, and no further description is given here. The various modules in the database transaction management device described above may be implemented in whole or in part by software, hardware, and combinations thereof. The above modules may be embedded in hardware or may be independent of a processor in the computer device, or may be stored in software in a memory in the computer device, so that the processor may call and execute operations corresponding to the above modules.
In one embodiment, a computer device is provided, which may be a server, the internal structure of which 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 includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The database of the computer device is used for storing data of a method for managing database transactions. The network interface of the computer device is used for communicating with an external terminal through a network connection. The computer program, when executed by a processor, implements a method of managing database transactions.
It will be appreciated by those skilled in the art that the structure shown in FIG. 6 is merely a block diagram of some of the structures associated with the present inventive arrangements and is not limiting of the computer device to which the present inventive arrangements may be applied, and that a particular computer device may include more or fewer components than shown, or may combine some of the 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 computer program is executed.
In one embodiment, a computer readable storage medium is provided, on which a computer program is stored which, when executed by a processor, implements the steps of the various embodiments described above.
Those skilled in the art will appreciate that implementing all or part of the above described methods may be accomplished by way of a computer program stored on a non-transitory computer readable storage medium, which when executed, may comprise the steps of the embodiments of the methods described above. Any reference to memory, storage, database, or other medium used in embodiments provided herein may include non-volatile and/or volatile memory. The nonvolatile 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 (SYNCHLINK) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), among others.
The technical features of the above embodiments may be arbitrarily combined, and all possible combinations of the technical features in the above embodiments are not described for brevity of description, however, as long as there is no contradiction between the combinations of the technical features, they should be considered as the scope of the description.
The above examples illustrate only a few embodiments of the application, which are described in detail and are not to be construed as limiting the scope of the application. It should be noted that it will be apparent to those skilled in the art that several variations and modifications can be made without departing from the spirit of the application, which are all within the scope of the application. Accordingly, the scope of protection of the present application is to be determined by the appended claims.

Claims (13)

1. A method of managing database transactions, the method comprising:
Acquiring a transaction starting request, wherein the transaction starting request comprises a database transaction, distributing a database transaction identifier for the database transaction, and recording the state of the database transaction identifier as started; the database transaction refers to a database operation sequence for accessing and operating various data items;
Determining a database identifier corresponding to a database for executing preset database operation for the first time in the database transaction as a first type of 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 first time later performing a preset database operation refers to a second and subsequent preset database operations in the database transaction;
determining the database operation corresponding to the first type database identifier as a single-database transaction to be started, and executing the single-database transaction;
Determining database operation corresponding to the second class database identifier as a distributed transaction to be started, and executing the distributed transaction;
receiving a transaction commit request, wherein the transaction commit request carries the database transaction identifier;
When the number of the database identifications in the database transaction corresponding to the database transaction identifications is a plurality of, determining a first type database identification and a second type database identification in the database identifications;
Recording a commit log of the distributed transaction corresponding to the second class database identifier in a first database corresponding to the first class database identifier;
Submitting the commit log recorded in the first database and the single-database transaction corresponding to the first database once;
If the primary submission is successful, performing secondary submission on the distributed transaction corresponding to the second class database identifier;
and ending the database transaction corresponding to the database transaction identifier if the secondary submission is successful.
2. The method according to claim 1, wherein the method further comprises:
acquiring a database identifier from a database transaction corresponding to the database transaction identifier;
And when the number of the database identifiers is single, determining that the database identifiers are the first type of database identifiers, submitting single-database transactions corresponding to the database identifiers, and ending the single-database transactions.
3. The method of claim 1, wherein the recording, in the first database corresponding to the first type of database identifier, a commit log of the distributed transaction corresponding to the second type of database identifier, comprises:
Receiving a submitting preparation stage request, and connecting with a second database corresponding to the second class database identifier in turn according to the submitting preparation stage request, so that the second database corresponding to the second class database identifier executes submitting preparation;
acquiring database operation data of the distributed transaction executed by the second database;
And after the second database commit preparation is completed, sequentially recording distributed database operation data executed by each second database in a corresponding transaction execution log in a first database corresponding to the first type database identifier to obtain the commit log.
4. The method according to claim 1, wherein the method further comprises:
If the one-time submission fails, rollback is carried out on the distributed transaction corresponding to the second class database identifier;
And if the rollback is successful, ending the database transaction corresponding to the database transaction identifier.
5. The method according to claim 1, wherein the method further comprises:
If the rollback fails, retrying the distributed transaction corresponding to the second class 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 class database identifier to generate alarm information.
6. The method according to claim 1, wherein the method further comprises:
If the secondary submission fails, retrying the distributed transaction corresponding to the second class database identifier 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 to generate 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 includes:
Querying the database transaction identifier in the submitted log, and querying whether a second class database identifier corresponding to the database transaction identifier has an uncommitted distributed transaction or not;
and if so, submitting the uncommitted distributed transaction in a second database corresponding to the corresponding second class database identifier.
8. The method according to claim 2, wherein the method further comprises:
Querying a suspended distributed transaction when a transaction management server fails, and executing submission or rollback on the queried distributed transaction;
if the execution commit or rollback is successful, recovering from the fault;
And if the queried distributed transaction has the distributed transaction with the execution submission failure or the rollback failure, generating alarm information.
9. The method according to claim 2, wherein the method further comprises:
and when the database corresponding to the database identifier fails, retrying the distributed transaction corresponding to the second database identifier.
10. A database transaction management device, the device 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, a database transaction identifier is distributed for the database transaction, and the state of the database transaction identifier is recorded as started; the database transaction refers to a database operation sequence for accessing and operating various data items;
The determining module is used for determining a database identifier corresponding to a database for executing preset database operation for the first time in the database transaction as a first type of 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 first time later performing a preset database operation refers to a second and subsequent preset database operations in the database transaction;
The control module determines the database operation corresponding to the first type database identifier as a single-database transaction to be started, and executes the single-database transaction; determining database operation corresponding to the second class database identifier as a distributed transaction to be started, and executing the distributed transaction;
Receiving a transaction commit request, wherein the transaction commit request carries the database transaction identifier; when the number of the database identifications in the database transaction corresponding to the database transaction identifications is a plurality of, determining a first type database identification and a second type database identification in the database identifications; recording a commit log of the distributed transaction corresponding to the second class database identifier in a first database corresponding to the first class database identifier; submitting the commit log recorded in the first database and the single-database transaction corresponding to the first database once; if the primary submission is successful, performing secondary submission on the distributed transaction corresponding to the second class database identifier; and ending the database transaction corresponding to the database transaction identifier if the secondary submission is successful.
11. The apparatus of claim 10, further comprising a commit module configured to obtain a database identifier from a database transaction corresponding to the database transaction identifier; and when the number of the database identifiers is single, determining that the database identifiers are the first type of database identifiers, submitting single-database transactions corresponding to the database identifiers, and ending the single-database transactions.
12. A computer device comprising a memory and a processor, the memory storing a computer program executable on the processor, characterized in that the processor implements the steps of the method of any one of claims 1 to 9 when the computer program is executed.
13. A computer readable storage medium, on which a computer program is stored, characterized in that the computer program, when being executed by a processor, implements the steps of the method of any of claims 1 to 9.
CN202011634397.1A 2020-12-31 2020-12-31 Database transaction management method, device, computer equipment and storage medium Active CN112765126B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011634397.1A CN112765126B (en) 2020-12-31 2020-12-31 Database transaction management method, device, computer equipment and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011634397.1A CN112765126B (en) 2020-12-31 2020-12-31 Database transaction management method, device, computer equipment and storage medium

Publications (2)

Publication Number Publication Date
CN112765126A CN112765126A (en) 2021-05-07
CN112765126B true CN112765126B (en) 2024-07-16

Family

ID=75697896

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011634397.1A Active CN112765126B (en) 2020-12-31 2020-12-31 Database transaction management method, device, computer equipment and storage medium

Country Status (1)

Country Link
CN (1) CN112765126B (en)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114003644B (en) * 2021-10-21 2022-11-15 河南星环众志信息科技有限公司 Distributed transaction processing method, device, medium and database system

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102567399A (en) * 2010-12-31 2012-07-11 北京新媒传信科技有限公司 Method and device for accessing database

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102306200B (en) * 2011-09-22 2013-03-27 用友软件股份有限公司 Device and method for concurrently applying incremental data manipulation statements
CN102306197B (en) * 2011-09-22 2013-07-03 用友软件股份有限公司 Device and method for guaranteeing consistency of data-source-crossing operation results
GB2511222A (en) * 2011-09-30 2014-08-27 Ibm Transaction processing system, method and program
CN103077222B (en) * 2012-12-31 2016-01-27 中国科学院计算技术研究所 Cluster file system distributed meta data consistance ensuring method and 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
CN108279986B (en) * 2017-12-29 2023-10-03 亿阳安全技术有限公司 Distributed transaction processing method and device
CN108733457B (en) * 2018-04-12 2021-07-20 创新先进技术有限公司 Method and device for realizing distributed transaction
CN108733589B (en) * 2018-04-12 2021-11-02 创新先进技术有限公司 Method and device for realizing distributed transaction hot deployment
CN110347481A (en) * 2019-07-17 2019-10-18 北京搜狐新媒体信息技术有限公司 A kind of method and system for realizing distributed transaction
CN111209142B (en) * 2020-01-02 2024-09-13 中国平安财产保险股份有限公司 Cross-database transaction management method, device, equipment and storage medium

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102567399A (en) * 2010-12-31 2012-07-11 北京新媒传信科技有限公司 Method and device for accessing database

Also Published As

Publication number Publication date
CN112765126A (en) 2021-05-07

Similar Documents

Publication Publication Date Title
US8527459B2 (en) System and method for data replication between heterogeneous databases
EP3117349B1 (en) System and method for massively parallel processing database
WO2016180164A1 (en) Method and apparatus for rolling back distributed transaction
EP2825957B1 (en) Systems and methods for supporting inline delegation of middle-tier transaction logs to database
EP2825958B1 (en) Systems and methods for supporting transaction recovery based on a strict ordering of two-phase commit calls
JPS633341B2 (en)
US20220229822A1 (en) Data processing method and device for distributed database, storage medium, and electronic device
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
CN115145697A (en) Database transaction processing method and device and electronic equipment
KR20140047448A (en) Client and database server for resumable transaction and method thereof
CN112765126B (en) Database transaction management method, device, computer equipment and storage medium
CN117234670B (en) Distributed transaction processing method, system, computer equipment and storage medium
CN111124751B (en) Data recovery method and system, data storage node and database management node
WO2024098363A1 (en) Multicore-processor-based concurrent transaction processing method and system
US12093139B2 (en) Rolling back a database transaction
CA3191210A1 (en) Data syncronization method and device, computer equipment and storage medium
CN114756408A (en) Metadata backup recovery method and device, electronic equipment and storage medium
KR102123616B1 (en) Method and apparatus for parallel journaling using conflict page list
CN112631741A (en) Transaction processing method, device and storage medium
CN112559457A (en) Data access method and device
CN110096389A (en) A kind of starting method, apparatus, equipment and the storage medium of database
CN112749156A (en) Data processing method, database management system and data processing equipment
CN113296966B (en) Data processing method and device
US20220382635A1 (en) Method and apparatus for processing transaction

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
GR01 Patent grant
GR01 Patent grant