CN106033437B

CN106033437B - Distributed transaction processing method and system

Info

Publication number: CN106033437B
Application number: CN201510111872.XA
Authority: CN
Inventors: 张松树
Original assignee: Alibaba Group Holding Ltd
Current assignee: Guangzhou Jianyue Information Technology Co.,Ltd.
Priority date: 2015-03-13
Filing date: 2015-03-13
Publication date: 2020-01-10
Anticipated expiration: 2035-03-13
Also published as: CN106033437A

Abstract

A distributed transaction processing method and system, the method includes: after receiving the SQL statement of the transaction branch, the transaction branch processing unit corresponding to each transaction branch of the distributed transaction sends the SQL statement of the transaction branch to the isolation controller for locking; the isolation controller obtains each data row corresponding to the business branch SQL statement from the database by query, and after obtaining the locking record corresponding to each data row from the business lock table query of the database, the isolation controller locks the data rows of the distributed business which are not locked in each data row by writing the locking record into the business lock table; the locking record comprises a global transaction identifier of the distributed transaction; after the locking operation is successful, the transaction branch processing unit executes the transaction branch SQL statement; and after receiving the transaction branch submitting instruction or the transaction branch rollback instruction, the transaction branch processing unit instructs the isolation controller to delete the locking record corresponding to the global transaction identifier from the transaction lock table according to the global transaction identifier.

Description

Distributed transaction processing method and system

Technical Field

The present application relates to the field of distributed data processing, and in particular, to a distributed transaction processing method and system.

Background

A distributed transaction typically contains multiple local transaction branches, each of which may operate on a respective database. Multiple distributed transactions may be concurrently executed on a database, and each distributed transaction may require operations such as INSERT (INSERT), DELETE (DELETE), modify (UPDATE), query (SELECT), etc. to be performed on multiple tables of the database. In this case, the database needs to ensure that before the modification operation of each distributed transaction on the database is submitted, the data row corresponding to the modification is invisible to other distributed transactions; or other words, other distributed transactions cannot be read to the intermediate state of the distributed transaction, and the isolation of the distributed transaction is guaranteed.

For example, for a transaction in which account a transfers 100 dollars to account B, implementing the transaction may require adding 100 dollars to account B and then subtracting 100 dollars from account a; in this case, other transactions (e.g., account inquiry transactions) cannot be made to see the status that account B has increased in amount, but account A has not yet been debited. Otherwise, once the deduction action on account a fails, the increased 100 elements in account B may have been subtracted by other transactions, so that a rollback operation against account B will fail.

Techniques to address the isolation problem of distributed transactions described above include: database locks, copy-on-write, multi-versioning, etc.

An existing distributed relational database system, such as MySQL, generally employs an XA two-phase commit protocol to manage distributed transactions, and employs a stand-alone database lock to perform concurrent control of distributed transactions, so as to ensure isolation of distributed transactions. The first stage of the XA two-stage submission protocol is a voting stage, and in the voting stage, all participants send feedback information about whether the transaction branch can be successfully executed to the coordinator; the second phase is the execution phase, where the coordinator informs all participants to commit in lockstep on all transaction branches, or roll back on all transaction branches, based on feedback information sent by all participants. When each participant performs local operation, the database lock competition is performed, the two-stage operation can be performed only when the lock is acquired first, and otherwise, the transaction branch execution failure is reported. The XA two-phase commit protocol requires the database itself to implement the protocol, and the performance of concurrency control in a distributed environment is completely dependent on how well the database system itself implements the protocol.

The XA two-phase commit protocol is a blocking protocol, when the database system implements the protocol, the database system requires to wait for completion of the slowest transaction branch in each phase of a distributed transaction, even if different transaction branches of the distributed transaction do not operate the same data row, and no lock conflict exists, database connections of the transaction branches are still suspended, and resources occupied by all the transaction branches cannot be released, so that the resources such as database locks are released in the second phase, and the problems that data inconsistency caused by releasing the resources before the distributed transaction (global transaction) is committed, and the intermediate state of the distributed transaction is read by other distributed transactions are solved. For large-scale internet enterprises with extremely high traffic, it is difficult to accept the huge performance overhead brought by the XA two-phase commit protocol.

Furthermore, if the database system uses MySQL, there is also a risk of data inconsistency when implementing the XA two-phase commit protocol. Specifically, the primary and standby synchronization of the MySQL database is completed by copying Binlog (log file of MySQL database), and for the performance, the Binlog records only the log (Commit log) of the distributed transaction in the second stage and does not record the log (Prepare log) of the distributed transaction in the first stage. If the first stage of all the transaction branches of the distributed transaction is completed and the global transaction is not submitted yet, a certain main database (main library) is down, and the Prepare logs of the corresponding transaction branches are not synchronized to the corresponding standby libraries at this time, so that data inconsistency occurs between the main library and the standby libraries, which is an intolerable error in actual service.

Disclosure of Invention

The application aims to provide a distributed transaction processing method and system.

In order to achieve the above object, the present application discloses a distributed transaction processing method, including:

after receiving the SQL statement of the transaction branch, the transaction branch processing unit corresponding to each transaction branch of the distributed transaction sends the SQL statement of the transaction branch to the isolation controller for locking;

the isolation controller obtains each data row corresponding to the affair branch SQL statement from a database query, and after obtaining a locking record corresponding to each data row from a affair lock table query of the database query, the isolation controller locks the data rows of the distributed affairs which are not locked in each data row by writing the locking record into the affair lock table; the locking record comprises a global transaction identifier of the distributed transaction;

after the locking operation is successful, the transaction branch processing unit executes the transaction branch SQL statement;

and after receiving the transaction branch submitting instruction or the transaction branch rollback instruction, the transaction branch processing unit instructs the isolation controller to delete the locking record corresponding to the global transaction identifier from the transaction lock table according to the global transaction identifier.

In addition, the locking record also contains the following fields as the unique index of the transaction lock table: table names of tables to which the data rows belong, primary key values of the data rows and mutual exclusion lock marks;

and when the mutual exclusion lock is applied to the data row, setting the mutual exclusion lock mark field in the locking record as a preset mutual exclusion lock mark value.

In addition, a share lock is applied to the data line as follows:

if no other distributed transaction is the corresponding data row sharing lock at present, writing two rows of locking records into the transaction lock table as the corresponding data row sharing lock: the value of the mutual exclusion lock mark field of one row of locking records is the preset mutual exclusion lock mark value, and the value of the mutual exclusion lock mark field of the other row of locking records is the global transaction identifier;

and if other distributed transactions add the shared lock to the corresponding data row, writing a locking record in a row into the transaction lock table to add the shared lock to the corresponding data row, wherein the value of the mutually exclusive lock mark field of the locking record is the global transaction identifier.

In addition, the method further comprises:

after receiving the read submitted query statement, the transaction branch processing unit sends the read submitted query statement to the isolation controller;

the isolation controller obtains each data row corresponding to the read submitted query statement from a database query, and judges whether other distributed transactions are mutually exclusive locks on one or more rows in each data row corresponding to the read submitted query statement after obtaining locking records corresponding to each data row from a transaction lock table query of the database; if not, returning each data line corresponding to the read submitted query statement to the transaction branch processing unit;

the read committed query statement is a query statement that contains annotation information for declaring intermediate states for which no other distributed transactions are read.

In addition, the method further comprises:

the submission direction of the distributed transaction registers the distributed transaction with a transaction manager, and after the distributed transaction is registered, the transaction branch SQL statement is sent to a transaction branch processing unit;

after receiving the transaction branch SQL statement and before sending the transaction branch SQL statement to an isolation controller, a transaction branch processing unit registers a transaction branch corresponding to the transaction branch SQL statement to a transaction manager;

after the affair branch SQL statement is executed, the affair branch processing unit reports the execution state of the affair branch to the submitter of the distributed affair or to the submitter of the distributed affair and the affair manager.

In addition, the method further comprises:

the submitter of the distributed transaction submits the distributed transaction by sending a global transaction submitting instruction to a transaction manager; the committer of the distributed transaction rolls back the distributed transaction by sending a global transaction roll-back instruction to a transaction manager;

the transaction manager sends the transaction branch submitting instruction to each transaction branch processing unit after receiving the global transaction submitting instruction; and after receiving the global transaction rollback instruction or when not receiving the global transaction commit instruction sent by the submitter of the distributed transaction within a preset time, the transaction manager sends the transaction branch rollback instruction to each transaction branch processing unit.

In order to achieve the above object, the present application also discloses a distributed transaction processing system, which includes: the system comprises a transaction branch processing unit, an isolation controller and a database, wherein the transaction branch processing unit corresponds to each transaction branch of a distributed transaction; wherein:

the transaction branch processing unit is used for sending the transaction branch SQL statement to the isolation controller for locking operation after receiving the transaction branch SQL statement;

the isolation controller is used for writing locking records into a transaction lock table to lock the data rows of the distributed transaction which are not locked in the data rows after the data rows corresponding to the transaction branch SQL statement are obtained by querying the database and the locking records corresponding to the data rows are obtained by querying the transaction lock table of the database; the locking record comprises a global transaction identifier of the distributed transaction;

the transaction branch processing unit is also used for executing the transaction branch SQL statement after the locking operation is successful;

and the transaction branch processing unit is further used for indicating the isolation controller to delete the locking record corresponding to the global transaction identifier from the transaction lock table according to the global transaction identifier after receiving the transaction branch submission instruction or the transaction branch rollback instruction.

when the mutual exclusion lock is added to the data row, the isolation controller sets the mutual exclusion lock mark field in the locking record to be a preset mutual exclusion lock mark value.

In addition, the isolation controller adds a shared lock to the data line as follows:

In addition, the transaction branch processing unit is also used for sending the read submitted query statement to the isolation controller after receiving the read submitted query statement;

the isolation controller is further used for judging whether other distributed transactions are mutually exclusive locks on one or more rows in the data rows corresponding to the read submitted query statement or not after the data rows corresponding to the read submitted query statement are obtained through query from a database and locking records corresponding to the data rows are obtained through query from a transaction lock table of the database; if not, returning each data line corresponding to the read submitted query statement to the transaction branch processing unit;

In addition, the system also comprises: a submitter of the distributed transaction, a transaction manager; wherein:

the submitter of the distributed transaction is used for registering the distributed transaction with the transaction manager and sending the transaction branch SQL statement to the transaction branch processing unit after the distributed transaction is registered;

the transaction branch processing unit is further used for registering the transaction branch corresponding to the transaction branch SQL statement to a transaction manager after receiving the transaction branch SQL statement and before sending the transaction branch SQL statement to the isolation controller;

and the transaction branch processing unit is also used for reporting the execution state of the transaction branch to the submitter of the distributed transaction or to the submitter of the distributed transaction and the transaction manager after the transaction branch SQL statement is executed.

In addition, the submitter of the distributed transaction is further configured to submit the distributed transaction by sending a global transaction submission instruction to the transaction manager;

the submitter of the distributed transaction is also used for rolling back the distributed transaction by sending a global transaction roll-back instruction to the transaction manager;

the transaction manager is also used for sending the transaction branch submitting instruction to each transaction branch processing unit after receiving the global transaction submitting instruction;

and the transaction manager is further used for sending the transaction branch rollback instruction to each transaction branch processing unit after receiving the global transaction rollback instruction or when not receiving the global transaction commit instruction sent by the submitter of the distributed transaction within a preset time.

Compared with the prior art, the technical effects that can be obtained by the application include:

(1) after each transaction branch of the distributed transaction completes the first-stage processing, system resources such as database connection and the like can be immediately released and returned, and the global transaction identifier is used for cleaning the database lock in the second stage, so that the database lock does not need to be hung up, other transaction branches are waited, and the consumption of the system resources is reduced;

(2) the transaction lock table of the service database is used for locking data, so that the dependence on a Prepare log is not required, and the safety of information such as database locks is improved;

(3) by adopting an efficient locking mode, the Read Committed isolation level of the distributed transaction is realized, and the service requirements of high concurrency and high throughput are met.

Of course, it is not necessary for any product to achieve all of the above-described technical effects simultaneously.

Drawings

The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the application and together with the description serve to explain the application and not to limit the application. In the drawings:

FIG. 1 is a flow chart of a method of a distributed transaction processing method according to an embodiment of the present application;

FIG. 2 is a method flow diagram of another distributed transaction processing method of an embodiment of the present application;

FIG. 3 is a method flow diagram of another distributed transaction processing method of an embodiment of the present application;

FIG. 4 is a method flow diagram of another distributed transaction processing method of an embodiment of the present application;

fig. 5 is a system configuration diagram of a distributed transaction processing system according to an embodiment of the present application.

Detailed Description

Embodiments of the present application will be described in detail with reference to the drawings and examples, so that how to implement technical means to solve technical problems and achieve technical effects of the present application can be fully understood and implemented.

In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include non-transitory computer readable media (transient media), such as modulated data signals and carrier waves.

Description of the embodiments

The following is a further illustration of the implementation of the method of the present application in one embodiment. The distributed transaction processing method is divided into two stages; the first stage executes the database operation of the distributed transaction, and the second stage cleans up the database lock. Fig. 1 is a flowchart of a method of a distributed transaction processing method according to an embodiment of the present application, where the method includes:

step S100: after receiving the SQL statement of the transaction branch, the transaction branch processing unit corresponding to each transaction branch of the distributed transaction sends the SQL statement of the transaction branch to the isolation controller for locking;

step S102: the isolation controller queries and obtains each data row corresponding to the transaction branch SQL statement from a database;

step S104: the isolation controller inquires from a transaction lock table of the database to obtain locking records corresponding to all data rows;

the locking record includes a global transaction identifier for the distributed transaction.

Step S106: the isolation controller locks the data rows of the distributed transaction which are not locked in each data row by writing locking records into a transaction lock table;

step S108: after the locking operation is successful, the transaction branch processing unit executes the transaction branch SQL statement;

step S110: and after receiving the transaction branch submitting instruction or the transaction branch rollback instruction, the transaction branch processing unit instructs the isolation controller to delete the locking record corresponding to the global transaction identifier from the transaction lock table according to the global transaction identifier.

The implementation of the method of the present application is further illustrated in a second embodiment. Fig. 2 is a flowchart of another method of a distributed transaction processing method according to an embodiment of the present application, where operations to be executed in a first phase of the distributed transaction processing method are described in detail in this embodiment; the method comprises the following steps:

step S200: the submitter of the global transaction (application) sends a global transaction registration request to the coordinator of the distributed transaction (transaction manager) to perform registration of the global transaction.

Step S202: after receiving the global transaction registration request, the transaction manager allocates a global transaction identifier for the corresponding global transaction, and sends the global transaction identifier to the application program in a global transaction registration response;

a global transaction is a transaction involving multiple resource managers (databases), and includes multiple transaction branches, each of which performs operations on one resource manager (database or a different connection to a database).

In this step, the application may save the global transaction identifier in the context of the thread to which the application belongs.

Step S204: the application program divides an SQL (Structured Query Language) statement (hereinafter, referred to as a global transaction SQL statement) corresponding to a global transaction into a plurality of SQL statements (hereinafter, referred to as transaction branch SQL statements) corresponding to different transaction branches respectively, and the transaction branch SQL statement is contained in a transaction branch execution request and is sent to each participant (transaction branch processing unit) respectively;

optionally, in this step, the application program may send the global transaction identifier to each transaction branch processing unit together with the transaction branch SQL statement.

Step S206: after receiving the transaction branch execution request, the transaction branch processing unit sends a transaction branch registration request to the transaction manager so as to register the transaction branch and declare the start of a new transaction branch;

when the transaction branch processing unit registers the transaction branch, the transaction manager needs to be provided with a global transaction identifier of the distributed transaction (also referred to as global transaction) to which the transaction branch belongs, so that the transaction manager associates the transaction branch with the distributed transaction to which the transaction branch belongs.

If the transaction branch processing unit runs in the same thread as the application, the transaction branch processing unit may extract the global transaction identifier from the context of the current thread to perform registration of the transaction branch.

If the application sends the global transaction identifier to the transaction branch processing unit in step S204, the transaction branch processing unit may use the global transaction identifier it received to perform the registration of the transaction branch.

Step S208: after receiving the transaction branch registration request, the transaction manager allocates a transaction branch identifier to the corresponding transaction branch and returns the transaction branch identifier to the transaction branch processing unit;

in this step, the transaction manager may include the transaction branch identifier in the transaction branch registration response back to the transaction branch processing unit.

Step S210: after receiving the transaction branch identifier, the transaction branch processing unit saves the transaction branch identifier and sends a locking request to the isolation controller;

the locking request may include the following information: database lock type, transaction branch SQL statement.

The types of the database lock are as follows: mutual exclusion lock, shared lock.

The database locks in the application are row-level locks, namely the locking unit of each database lock is a data row; wherein: a mutual exclusive lock allows a distributed transaction owning the lock to query, update or delete the locked data row, and a shared lock allows a distributed transaction owning the lock to query the locked data row.

In order to achieve the isolation of the distributed transaction, before a certain data row is read by the distributed transaction, a database lock (a mutual exclusion lock or a shared lock) of the data row needs to be owned by the distributed transaction, that is, any transaction branch of the distributed transaction has successfully added the database lock (the mutual exclusion lock or the shared lock) to the data row; and if the distributed transaction adds the mutual exclusion lock to a certain data row, any distributed transaction is not allowed to add any database lock to the data row, namely any locking operation aiming at the data row in the subsequent step fails.

In addition, on the basis of realizing the isolation of the distributed transactions, in order to improve the concurrency of the distributed transactions, the data change of the read operation is considered not to occur, so when one distributed transaction adds a shared lock to a certain data row, other distributed transactions are allowed to add the shared lock to the data row again, but the mutual exclusion lock is not allowed to be added to the data row; that is, the operation of adding the shared lock to the data line in the subsequent step will succeed, but the operation of adding the exclusive lock to the data line will fail.

In addition, when any transaction branch of the distributed transaction has added a database lock (exclusive lock or shared lock) for a certain data row, it means that all transaction branches of the distributed transaction possess the database lock for the data row, and other transaction branches of the distributed transaction do not need to repeatedly add locks for the data row to ensure that the intermediate state of the distributed transaction is visible inside the distributed transaction.

In the embodiment, the transaction branch SQL statement can be used as a locking request, and the isolation controller judges the type of the database lock according to the type of the SQL statement; for example:

adding a mutual exclusion lock to the operations of INSERT (INSERT), modify (UPDATE), DELETE (DELETE) and UPDATE mode lock query (SELECT … FOR UPDATE);

a LOCK query (SELECT … LOCK IN SHARE MODE) operation for shared MODE adds the shared LOCK.

In this step, the transaction branch processing unit may save the transaction branch identifier in the context of the thread to which it belongs.

In this step, the transaction branch processing unit may also include the global transaction identifier and the transaction branch identifier in the locking request and send the locking request to the isolation controller.

Step S212: the isolation controller analyzes the received transaction branch SQL statement, generates a corresponding data set query statement according to the transaction branch SQL statement, and sends the data set query statement to a database to obtain a data set corresponding to the transaction branch SQL statement;

the generation mode of the data set query statement is respectively described according to different types of the transaction branch SQL statement as follows:

(1) if the transaction branch SQL statement is an INSERT (INSERT) statement, a data set query statement is generated in the following way:

taking a table name contained in a transaction branch SQL statement (INSERT statement) as a target table name of a data set query statement;

analyzing each field expected to be inserted by the transaction branch SQL statement (INSERT statement), if the transaction branch SQL statement (INSERT statement) does not contain a main key, taking all fields (columns) contained in the table as result fields (columns) of the data set query statement, and taking all fields and field values contained in the transaction branch SQL statement (INSERT statement) as query conditions of the data set query statement; if the table main key is contained, taking the table main key as a result field (column) of the data set query statement, and using the main key and a corresponding main key value as a query condition of the data set query statement;

for example, a transaction branch SQL statement is:

INSERT INTO table_name(column1,column2)VALUES(v1,v2)；

wherein, table _ name is the table name of the transaction branch SQL statement; column1, column2 is the field names of all the fields (columns) contained in the transaction branch SQL statement; v1 and v2 are the field values of the above fields respectively; the corresponding dataset query statement may be:

SELECT*FROM table_name WHERE((column1＝v1)AND(column2＝v2))；

if column1 is the primary key of table _ name, the corresponding dataset query statement may be:

SELECT column1FROM table _ name WHERE (column1 ═ v 1); or

SELECT*FROM table_name WHERE(column1＝v1)。

(2) If the transaction branch SQL statement is a modify (UPDATE) statement, a dataset query statement is generated as follows:

taking a table name contained in a transaction branch SQL statement (UPDATE statement), namely the table name of a table expected to be updated as a target table name of a data set query statement;

analyzing each field and a WHERE clause of a transaction branch SQL statement (UPDATE statement), if the transaction branch SQL statement (UPDATE statement) does not contain a main key, taking all fields (columns) contained in the table as result fields (columns) of the data set query statement, and taking the WHERE clause of the transaction branch SQL statement as a query condition of the data set query statement; if the table main key is contained, taking the table main key as a result field (column) of the data set query statement, and using the main key and a corresponding main key value as a query condition of the data set query statement;

for example, a transaction branch SQL statement is:

UPDATE table_name SET column3＝v3 WHERE((column1＝v1)AND(column2＝v2))；

wherein, table _ name is the table name of the transaction branch SQL statement; column1, column2, and column3 are field names of all fields (columns) included in the transaction branch SQL statement; v1, v2 and v3 are field values of the above fields respectively; the corresponding dataset query statement may be:

SELECT*FROM table_name WHERE((column1＝v1)AND(column2＝v2))；

SELECT column1FROM table _ name WHERE (column1 ═ v 1); or

SELECT*FROM table_name WHERE(column1＝v1)。

(3) If the transactional branch SQL statement is a DELETE (DELETE) statement, then a dataset query statement is generated as follows:

taking a table name contained in a transaction branch SQL statement (DELETE statement), namely the table name of a table expected to DELETE data as a target table name of a data set query statement;

analyzing each field and a WHERE clause of a transaction branch SQL statement (DELETE statement), if the transaction branch SQL statement (DELETE statement) does not contain a main key, taking all fields (columns) contained in the table as result fields (columns) of the data set query statement, and taking the WHERE clause of the transaction branch SQL statement as a query condition of the data set query statement; if the table main key is contained, taking the table main key as a result field (column) of the data set query statement, and using the main key and a corresponding main key value as a query condition of the data set query statement;

for example, a transaction branch SQL statement is:

DELETE column1,column2,column3 FROM table_name WHERE((column1＝v1)AND(column2＝v2))；

wherein, table _ name is the table name of the transaction branch SQL statement; column1, column2, and column3 are field names of all fields (columns) included in the transaction branch SQL statement; v1 and v2 are field values of column1 and column2 respectively; the corresponding dataset query statement may be:

SELECT*FROM table_name WHERE((column1＝v1)AND(column2＝v2))；

SELECT column1FROM table _ name WHERE (column1 ═ v 1); or

SELECT*FROM table_name WHERE(column1＝v1)。

(4) If the transactional branch SQL statement is a lock query in UPDATE mode (SELECT … FOR UPDATE) statement, then a dataset query statement is generated as follows:

taking the table name contained in the transaction branch SQL statement (SELECT … FOR UPDATE statement), namely the table name of the table expected to be queried as the target table name of the data set query statement;

analyzing each field and a WHERE clause of a transaction branch SQL statement (SELECT … FOR UPDATE statement), if the transaction branch SQL statement (SELECT … FOR UPDATE statement) does not contain a main key, taking all fields (columns) contained in the table as result fields (columns) of the data set query statement, and taking the WHERE clause of the transaction branch SQL statement as a query condition of the data set query statement; if the table main key is contained, taking the table main key as a result field (column) of the data set query statement, and using the main key and a corresponding main key value as a query condition of the data set query statement;

for example, a transaction branch SQL statement is:

SELECT column1,column2,column3 FROM table_name WHERE((column1＝v1)AND(column2＝v2))FOR UPDATE；

SELECT*FROM table_name WHERE((column1＝v1)AND(column2＝v2))；

SELECT column1FROM table _ name WHERE (column1 ═ v 1); or

SELECT*FROM table_name WHERE(column1＝v1)。

(5) If the transactional branch SQL statement is a LOCK query IN shared mode (SELECT … LOCK IN SHAREDODE) statement, then a dataset query statement is generated as follows:

taking the table name contained IN the transaction branch SQL statement (SELECT … LOCK IN SHARE MODE statement), namely the table name of the table expected to be queried as the target table name of the data set query statement;

analyzing each field and a WHERE clause of a transaction branch SQL statement (SELECT … LOCK IN SHARE MODE statement), if the transaction branch SQL statement (SELECT … LOCK IN SHARE MODE statement) does not contain a main key, taking all fields (columns) contained IN the table as result fields (columns) of the data set query statement, and taking the WHERE clause of the transaction branch SQL statement as a query condition of the data set query statement; if the table main key is contained, taking the table main key as a result field (column) of the data set query statement, and using the main key and a corresponding main key value as a query condition of the data set query statement;

for example, a transaction branch SQL statement is:

SELECT column1,column2,column3 FROM table_name WHERE((column1＝v1)AND(column2＝v2))LOCK IN SHARE MODE；

SELECT*FROM table_name WHERE((column1＝v1)AND(column2＝v2))；

SELECT column1FROM table _ name WHERE (column1 ═ v 1); or

SELECT*FROM table_name WHERE(column1＝v1)。

Step S214: the database executes the data set query statement it receives and returns to the isolation controller the data set (which may also be referred to as a query result set), denoted R1, to which the data set query statement corresponds.

Step S216: the isolation controller sends a locking record query request to the database according to the table name and the primary key value of the data row of the data table (short for table) to which each data row belongs in the R1, so that the locking record of the corresponding data row is queried from the transaction lock table of the database;

table 1 describes the table structure of the transaction lock table in the present application:

name of field	Type of field	Field description
			ID	BIGINT UNSIGNED	Self-increment key
TABLE_NAME	VARchar(100)	Table name
			KEY_VALUE	BIGINT UNSIGNED	Data row primary key value
XID	VARchar(100)	Global transaction identifier
			XLOCK	INT UNSIGNED	Mutual exclusion lock tag
SLOCK	INT UNSIGNED	Shared lock tokens
			BRANCH_ID	INT UNSIGNED	Transaction branch identifier

TABLE 1

As shown in table 1, the following fields are included in the transaction lock table: a transaction lock TABLE primary KEY (ID), a TABLE NAME (TABLE _ NAME), a data row primary KEY VALUE (KEY _ VALUE), a global transaction identifier (XID), a mutually exclusive lock flag (XLOCK), a shared lock flag (SLOCK), a transaction BRANCH identifier (BRANCH _ ID); wherein:

a transaction lock table primary key (ID) field is a primary key of the transaction lock table, the field may be an autonomous key, and the field type may be UNSIGNED large integer (big UNSIGNED);

the TABLE NAME (TABLE _ NAME) field is used for recording the NAME of the data TABLE to which the locked data row belongs, the field type can be a variable length character type (VARCHAR), and the length can be 100 bytes;

the data row primary KEY VALUE (KEY _ VALUE) field is used for recording the primary KEY VALUE corresponding to the locked data row, and the field type can be UNSIGNED large integer (big integer);

a global transaction identifier (XID) field for recording a global transaction identifier for a transaction locking a data line, the field type may be a variable length character (VARCHAR) type, and the length may be 100 bytes;

the exclusive lock flag (XLOCK) field is used for identifying whether the database lock type of the corresponding record (corresponding row) in the transaction lock table is an exclusive lock, and the field type can be UNSIGNED integer (INT UNSIGNED);

a shared lock flag (SLOCK) field is used for identifying whether a database lock type of a corresponding record (corresponding row) in the transaction lock table is a shared lock, and the field type can be UNSIGNED integer (INT UNSIGNED);

if the database lock type of the corresponding record is a mutual exclusion lock, the mutual exclusion lock flag value is a non-zero value (e.g., 1), and the shared lock flag value may be 0; if the database lock type of the corresponding record is a shared lock, the shared lock flag value is a non-zero value (e.g., 1).

The transaction BRANCH identifier (BRANCH _ ID) field is used to record the transaction BRANCH identifier of the transaction BRANCH locking the data line, and the field type can be UNSIGNED integer (INT UNSIGNED).

In order to facilitate locking operation for each data row by using the transaction lock TABLE, data row conflict detection is performed in the transaction lock TABLE, and a TABLE NAME (TABLE _ NAME), a data row primary KEY VALUE (KEY _ VALUE), and a mutual exclusion lock tag (XLOCK) are used as unique indexes of the transaction lock TABLE, that is, multiple records having the same TABLE NAME, the same data row primary KEY VALUE, and the same mutual exclusion lock tag at the same time are not allowed to exist in the transaction lock TABLE.

In addition, in order to increase the query speed, the TABLE NAME (TABLE _ NAME) and the global transaction identifier (XID) can be used as the common index of the transaction lock TABLE.

Step S218: the database extracts the locking record set of the corresponding data row from the transaction lock table according to the table name and the primary key value of the data row contained in the locking record query request, and records the locking record set as R2, and the locking record set is contained in the locking record query response and returned to the isolation controller.

Step S220: the isolation controller finds out a data set R3(R3 ═ R1-R2) which is not locked in the current distributed transaction from a query result set R1 corresponding to the transaction branch SQL statement according to the acquired locking record set R2, and locks each data row in the data set R3 by using the table name of the data table to which each data row belongs, the primary key value of each data row and the type of the database lock, namely writes each data row in the data set R3 into the transaction lock table;

when a mutex is added to a data row, the mutex flag in the mutex record is set to a preset mutex flag value (e.g., 1), the shared lock flag may be set to 0, and the mutex flag, the table name of the data table to which the data row belongs, the primary key value of the data row, the global transaction identifier of the current distributed transaction, and the transaction branch identifier of the current transaction branch are written into the transaction lock table.

Because the TABLE NAME (TABLE _ NAME), the primary KEY VALUE (KEY _ VALUE) of the data row and the exclusive lock tag (XLOCK) are the only indexes in the transaction lock TABLE, the repeated operation of adding the exclusive lock can be ensured to fail once the exclusive lock exists in the corresponding data row.

For example, the table name of the data table to which the data row belongs is T1, the primary key value of the data row is K1, the global transaction identifier of the current distributed transaction is XID1, the transaction branch identifier of the current transaction branch is BID1, and after the exclusive lock is applied to the data row, the corresponding record in the transaction lock table is as shown in table 2:

ID

TABLE_NAME

KEY_VALUE

XID

XLOCK

SLOCK

BRANCH_ID

IDn

T1

K1

XID1

1

0

BID1

TABLE 2

IDn in table 2 is the value of the primary key (ID) of the transaction lock table automatically generated by the database for the corresponding locking record when the record is written.

When a sharing lock is added to a data row, the isolation controller needs to judge whether other distributed transactions add the sharing lock to the corresponding data row according to the locking record set R2, and if no other distributed transactions add the sharing lock to the corresponding data row, the isolation controller adds the sharing lock to the corresponding data row by writing two rows of locking records into the transaction lock table;

one row of locking records can be called as implicit mutual exclusion locking records of the corresponding data row; setting a mutual exclusion lock flag in the record to a preset mutual exclusion lock flag value (for example, 1), setting a shared lock flag to be 1, and writing the shared lock flag, the table name of the data table to which the data row belongs, the primary key value of the data row, the global transaction identifier of the current distributed transaction, and the transaction branch identifier of the current transaction branch into the transaction lock table;

another row of locked records may be referred to as a shared lock record for the corresponding data row; setting the mutual exclusion lock flag in the record as a global transaction identifier of the current distributed transaction, where the shared lock flag may be set to a preset shared lock flag value (e.g., 1), and writing the shared lock flag value into the transaction lock table along with the table name of the data table to which the data row belongs, the primary key value of the data row, the global transaction identifier of the current distributed transaction, and the transaction branch identifier of the current transaction branch.

For example, if the table name of the data table to which the data row belongs is T1, the primary key value of the data row is K1, the global transaction identifier of the current distributed transaction is XID1, and the transaction branch identifier of the current transaction branch is BID1, if the data row does not have a corresponding locking record in the transaction lock table before, after the data row is locked for the first time, the corresponding record in the transaction lock table is as shown in table 3:

ID

TABLE_NAME

KEY_VALUE

XID

XLOCK

SLOCK

BRANCH_ID

IDn

T1

K1

XID1

1

BID1

IDn+1

T1

K1

XID1

1

BID1

TABLE 3

When a sharing lock is added to a data row, if the isolation controller determines that other distributed transactions add the sharing lock to the corresponding data row according to the locking record set R2, the corresponding sharing lock record only needs to be written into the transaction lock table by writing a locking record to the transaction lock table as the corresponding data row sharing lock.

For example, if the shared lock shown in table 3 has been written into the distributed transaction with the global transaction identifier XID1 for the data row with the table name T1 and the primary key value K1, when the transaction branch with the transaction branch identifier BID2 in the distributed transaction with the global transaction identifier XID2 is the shared lock for the data row, only the corresponding shared lock record needs to be written into the distributed transaction with the global transaction identifier XID2, and after the lock is successfully added, the record corresponding to the data row in the transaction lock table is shown in table 4:

ID

TABLE_NAME

KEY_VALUE

XID

XLOCK

SLOCK

BRANCH_ID

IDn

T1

K1

XID1

1

BID1

IDn+1

T1

K1

XID1

1

BID1

IDm

T1

K1

XID2

1

BID2

TABLE 4

Because the TABLE NAME (TABLE _ NAME), the primary KEY VALUE (KEY _ VALUE) of the data row and the exclusive lock flag (XLOCK) are unique indexes in the transaction lock TABLE, it can be ensured that once the exclusive lock exists in the corresponding data row, the operation of adding the shared lock to the corresponding data row fails.

Correspondingly, once the corresponding data line has the sharing lock, the operation of adding the mutual exclusion lock for the corresponding data line fails; meanwhile, different distributed transactions are allowed to add the shared lock for the same data line for multiple times, so the shared lock adding method is adopted, and the characteristic that the global transaction identifier (XID) of the distributed transactions is not repeated is utilized, so that the shared lock conflict is avoided.

In other embodiments of the present invention, the shared lock tag (SLOCK) field may be omitted from the transaction lock table, and only the exclusive lock tag (XLOCK) field is used to distinguish the database lock types of each locking record:

if a certain data row only has a row of locking records in the transaction lock table, the database lock type corresponding to the locking records is a mutual exclusion lock;

if a plurality of rows of locking records exist in the transaction lock table for a certain data row, the type of the database lock corresponding to the locking record is a shared lock.

Step S222: the database returns the execution result of the locking operation to the isolation controller, the isolation controller judges whether the locking operation is successful according to the execution result returned by the database, and if the locking operation is successful, the next step is executed; if the locking operation fails, the process goes to step S216 to query the locking record and perform the locking operation again.

As shown in step 220 and step 222, in this embodiment, since different transaction branches of the same distributed transaction do not need to repeatedly lock the same data row, the isolation controller first screens out a data set R3 that is not currently locked by the distributed transaction from the query result set R1, and locks each data row in the data set R3, that is, writes a corresponding record into the transaction lock table; according to the unique index in the transaction lock table and the specific modes of the mutual exclusion lock and the shared lock, when a certain distributed transaction adds the mutual exclusion lock to a certain data row, any locking operation aiming at the data row fails; when a distributed transaction adds a sharing lock to a data row, the operations of other distributed transactions on the data row with the sharing lock are successful, and the operations on the data row with the mutual exclusion lock fail.

Step S224: the isolation controller returns a locking response to the transaction branch processing unit to inform the transaction branch processing unit that the locking is successful.

Step S226: and after the locking is successful, the transaction branch processing unit sends the transaction branch SQL statement contained in the transaction branch execution request to the database so as to execute the corresponding transaction branch.

Step S228: after the SQL statement of the transaction branch is executed, the database returns a transaction branch execution response to the transaction branch processing unit so as to inform the transaction branch processing unit of the execution state of the transaction branch.

Step S230: the transaction branch processing unit sends a transaction branch status report request to the transaction manager to report the execution status of the transaction branch.

Step S232: after receiving the transaction branch state report request, the transaction manager records the corresponding transaction branch state information and returns a transaction branch state report response to the transaction branch processing unit;

after receiving the transaction branch status report response, the transaction branch processing unit may release the corresponding system resources such as database connections.

Step S234: the transaction branch processing unit returns a transaction branch execution response to the application program to inform the application program of the execution state of the transaction branch.

To this end, the first phase of the distributed transaction processing method is completed. In this stage, each transaction branch processing unit completes the database operation of the corresponding transaction branch, and can release the corresponding system resource after the database operation is completed.

The method of the present application is further illustrated in a third embodiment. Fig. 3 is a flowchart of another method of a distributed transaction processing method according to an embodiment of the present application, where details of operations that need to be executed in the second phase of the distributed transaction processing method are described in this embodiment; the method comprises the following steps:

step S300: a submitter (application) of the global transaction sends a global transaction commit instruction or a global transaction rollback instruction to a coordinator (transaction manager) of the distributed transaction to initiate commit or rollback of the distributed transaction;

the global transaction commit instruction includes a global transaction identifier of the distributed transaction.

The global transaction rollback instruction contains a global transaction identifier of the distributed transaction.

The application program can determine whether the global transaction should be submitted or not or roll back the global transaction according to the execution state of each transaction branch reported by each transaction branch processing unit;

if the execution state of each transaction branch reported by each transaction branch processing unit is successful, submitting the global transaction;

and if the execution state of the transaction branch reported by any transaction branch processing unit is the execution failure or overtime unreported execution state, rolling back the global transaction.

Step S302: the transaction manager returns a global transaction commit response or a global transaction rollback response to the application.

Step S304: if the transaction manager receives the global transaction commit instruction in step S300, sending a transaction branch commit instruction to each participant (transaction branch processing unit) of the distributed transaction to initiate the commit of each transaction branch of the distributed transaction; if the transaction manager receives the global transaction rollback instruction in step S300, sending a transaction branch rollback instruction to each participant (transaction branch processing unit) of the distributed transaction to initiate a rollback of each transaction branch of the distributed transaction;

the transaction branch commit instruction may include a global transaction identifier for the distributed transaction.

The transaction branch rollback instruction may include a global transaction identifier for the distributed transaction.

In addition, if the transaction manager does not receive the global transaction submission instruction sent by the application program registered with the distributed transaction within the preset time, the transaction manager indicates that the application program side is abnormal; in this case, even if a global transaction rollback instruction sent by the application program is not received, the transaction manager sends a transaction branch rollback instruction to each transaction branch processing unit corresponding to the global transaction, so as to drive each transaction branch processing unit to perform rollback of the transaction branch.

Step S306: after receiving a transaction branch submitting instruction or a transaction branch rollback instruction, the transaction branch processing unit sends a lock cleaning request to the isolation controller;

the lock clean request includes a global transaction identifier of the distributed transaction.

Step S308: after receiving the lock cleaning request, the isolation controller performs lock deletion operation according to the global transaction identifier included in the request, that is, deletes the record with the corresponding global transaction identifier included in the transaction lock table of the database.

Step S310: and the database returns the execution result of the lock deletion operation to the isolation controller.

Step S312: the isolation controller sends a lock clean response to the transactional branch processing unit to notify the transactional branch processing unit of the result of the execution of the lock elision operation.

Step S314: the transaction branch processing unit sends a transaction branch status report request to the transaction manager to report the execution status of the commit or rollback of the transaction branch.

As described above, in the second stage, when the transaction branch processing units commit and rollback the transaction branches, the lock deletion operation can be completed only by using the global transaction identifier without maintaining database connections and blocking database resources.

In the above embodiments of the present application, in order to prevent a certain distributed transaction from reading to the intermediate state of another distributed transaction, and implement the isolation level of Read Committed (Read Committed), a shared lock needs to be added to the corresponding data row before the distributed transaction performs a query operation. The following embodiments of the present application achieve the goal of preventing a certain distributed transaction from reading to the intermediate state of other distributed transactions in other ways.

The method of the present application is further illustrated by a fourth embodiment. Fig. 4 is a flowchart illustrating a method of another distributed transaction processing method according to an embodiment of the present application; the method comprises the following steps:

step S400: the submitter of the global transaction (application) sends a global transaction registration request to the coordinator of the distributed transaction (transaction manager) to perform registration of the global transaction.

Step S402: after receiving the global transaction registration request, the transaction manager allocates a global transaction identifier for the corresponding global transaction, and sends the global transaction identifier to the application program in a global transaction registration response;

Step S404: the application program divides an SQL (Structured Query Language) statement (hereinafter, referred to as a global transaction SQL statement) corresponding to a global transaction into a plurality of SQL statements (hereinafter, referred to as transaction branch SQL statements) corresponding to different transaction branches respectively, and the transaction branch SQL statement is contained in a transaction branch execution request and is sent to each participant (transaction branch processing unit) respectively;

In this embodiment, the transaction branch SQL statement received by the transaction branch processing unit is a read committed query statement.

Generally, most query operations (read operations) of distributed transactions do not care whether the intermediate state of other distributed transactions is read, and therefore, by default, no lock check is performed on the query operations, that is, no check is made as to whether the data line corresponding to the query operation is mutually exclusive locked by other distributed transactions. If no reads to the intermediate state of other distributed transactions are desired, the application may add comments (HINT) in the query statement (transaction branch SQL statement) to state that the query statement does not desire to read to the intermediate state of other distributed transactions, such statement being referred to herein as a read committed query statement. For example:

/*+TXC({'level':'readcommited'})*/SELECT column1 FROM table_name。

wherein, "/+ TXC ({ ' level ': readcommitted ' })/" is annotation information for declaring that the query statement does not wish to read to an intermediate state of other distributed transactions, i.e., wishes to implement a query that reads a committed isolation level; table _ name is the table name of the table that the query statement wishes to query; column1 is the field name of the field that the query statement wishes to query.

Step S406: after receiving the transaction branch execution request, the transaction branch processing unit sends a transaction branch registration request to the transaction manager so as to register the transaction branch and declare the start of a new transaction branch;

If the application sends the global transaction identifier to the transaction branch processing unit in step S404, the transaction branch processing unit may use the global transaction identifier it received to perform the registration of the transaction branch.

Step S408: after receiving the transaction branch registration request, the transaction manager allocates a transaction branch identifier to the corresponding transaction branch and returns the transaction branch identifier to the transaction branch processing unit;

Step S410: after receiving the transaction branch identifier, the transaction branch processing unit saves the transaction branch identifier and sends the read committed query statement to the isolation controller.

Step S412: the isolation controller analyzes the received read and submitted query statement, generates a corresponding data set query statement according to the read and submitted query statement, and sends the data set query statement to the database to obtain a data set corresponding to the read and submitted query statement;

in this step, a data set query statement is generated as follows:

reading a table name contained in the submitted query statement, namely taking the table name of a table expected to be queried as a target table name of the data set query statement;

analyzing each field and a WHERE clause of the read submitted query statement, if the read submitted query statement does not contain a main key, taking all fields (columns) contained in the table as result fields (columns) of the data set query statement, and taking the WHERE clause of the read submitted query statement as a query condition of the data set query statement; if the table main key is contained, the query statement with the annotation removed is used as a data set query statement;

for example, reading a submitted query statement is:

/*+TXC({'level':'readcommited'})*/SELECT column1,column2,column3FROMtable_name WHERE((column1＝v1)AND(column2＝v2))；

wherein, table _ name is the table name for reading the submitted query statement; column1, column2, column3 are field names for reading all fields (columns) contained in a submitted query statement; v1, v2 and v3 are field values of the above fields respectively;

if the read submitted query statement does not contain a primary key, the corresponding dataset query statement may be:

SELECT*FROM table_name WHERE((column1＝v1)AND(column2＝v2))；

SELECT column1,column2,column3 FROM table_name WHERE((column1＝v1)AND(column2＝v2))。

step S414: the database executes the data set query statement it receives and returns to the isolation controller the data set (which may also be referred to as a query result set), denoted R1, to which the data set query statement corresponds.

Step S416: the isolation controller sends a locking record query request to the database according to the table name and the primary key value of the data row of the data table (short for table) to which each data row belongs in the R1, so that the locking record of the corresponding data row is queried from the transaction lock table of the database;

preferably, in this step, the isolation controller may only query the locking record corresponding to the database lock type being the mutex lock.

Step S418: the database extracts the locking record set of the corresponding data row from the transaction lock table according to the table name and the primary key value of the data row contained in the locking record query request, and records the locking record set as R2, and the locking record set is contained in the locking record query response and returned to the isolation controller.

Step S420: the isolation controller judges whether the record which is locked by other distributed transactions in a mutual exclusion way is contained according to the acquired locking record set R2; if yes, indicating that the mutual exclusion lock conflict exists, and jumping to the step S416 to perform repeated inquiry; if not, it indicates that there is no mutual exclusion lock conflict, and returns the corresponding query result set to the transaction branch processing unit.

Step S422: the transaction branch processing unit sends a transaction branch status report request to the transaction manager to report the execution status of the transaction branch.

Step S424: after receiving the transaction branch state report request, the transaction manager records the corresponding transaction branch state information and returns a transaction branch state report response to the transaction branch processing unit;

Step S426: the transaction branch processing unit returns a transaction branch execution response to the application program to inform the application program of the execution state of the transaction branch.

To this end, the first phase of the distributed transaction processing method is completed.

The specific steps of the second phase of the distributed transaction processing method corresponding to this embodiment are the same as those shown in fig. 3, and are not described herein again.

The system of the present application is further described below in terms of another embodiment. As shown in fig. 5, a system structure diagram of a distributed transaction processing system according to an embodiment of the present application is shown, where the distributed transaction processing system includes: a transaction branch processing unit 500 corresponding to each transaction branch of the distributed transaction; an isolation controller 502, a database 504; wherein:

the transaction branch processing unit is further configured to instruct the isolation controller to delete the locking record corresponding to the global transaction identifier from the transaction lock table according to the global transaction identifier after receiving the transaction branch commit instruction or the transaction branch rollback instruction.

In addition, the transaction branch processing unit is also used for sending the read committed query statement to the isolation controller after receiving the read committed query statement;

The system also comprises: a submitter of the distributed transaction 506, a transaction manager 508; wherein:

the transaction branch processing unit is also used for registering a transaction branch corresponding to the transaction branch SQL statement to a transaction manager after receiving the transaction branch SQL statement and before sending the transaction branch SQL statement to the isolation controller;

the transaction branch processing unit is further configured to report an execution state of the transaction branch to a submitter of the distributed transaction or to the submitter of the distributed transaction and the transaction manager after executing the transaction branch SQL statement.

In addition, the submitter of the distributed transaction is also used for submitting the distributed transaction by sending a global transaction submitting instruction to the transaction manager;

the submitter of the distributed transaction is further configured to rollback the distributed transaction by sending a global transaction rollback instruction to a transaction manager;

the transaction manager is further configured to send the transaction branch rollback instruction to each transaction branch processing unit after receiving the global transaction rollback instruction or when not receiving the global transaction commit instruction sent by the committer of the distributed transaction within a preset time.

The foregoing description shows and describes several preferred embodiments of the present application, but as aforementioned, it is to be understood that the application is not limited to the forms disclosed herein, but is not to be construed as excluding other embodiments and is capable of use in various other combinations, modifications, and environments and is capable of changes within the scope of the inventive concept as expressed herein, commensurate with the above teachings, or the skill or knowledge of the relevant art. And that modifications and variations may be effected by those skilled in the art without departing from the spirit and scope of the application, which is to be protected by the claims appended hereto.

Claims

1. A method of distributed transaction processing, the method comprising:

2. The method of claim 1,

the locking record also contains the following fields as the unique index of the transaction lock table: table names of tables to which the data rows belong, primary key values of the data rows and mutual exclusion lock marks;

3. The method of claim 2,

the following method is adopted to add a sharing lock to the data row:

4. The method of claim 2,

the method further comprises the following steps:

5. The method of claim 1,

the method further comprises the following steps:

6. The method of claim 5,

the method further comprises the following steps:

7. A distributed transaction processing system, comprising: the system comprises a transaction branch processing unit corresponding to each transaction branch of the distributed transaction, an isolation controller, a database, a submitter of the distributed transaction and a transaction manager; wherein:

8. The system of claim 7,

9. The system of claim 8,

the isolation controller adds a sharing lock to the data row in the following way:

10. The system of claim 8,

the transaction branch processing unit is also used for sending the read submitted query statement to the isolation controller after receiving the read submitted query statement;

11. The system of claim 7,

12. The system of claim 7,

the submitter of the distributed transaction is also used for submitting the distributed transaction by sending a global transaction submitting instruction to the transaction manager;