Patent Description:
The present specification relates to the field of computer technologies, and particularly to data transaction processing methods, apparatuses, and electronic devices.

A database transaction is a basic work unit of a database, allowing the database to transition from one consistent state to another consistent state. A database transaction allows for simultaneously performing write operations on different data items in a database. These operations are either all executed successfully or all are not executed. Even if a failure occurs in a system, unfinished database transactions can still be correctly recovered. Database transactions can be isolated to different degrees to ensure the correctness of data.

Currently, in a distributed database, data is distributed on different machines. A database transaction often needs to access multiple machines. In order to ensure the atomicity of transactions, it is necessary to ensure that machines participating in a database transaction cooperate with each other. This process is very complicated and has a large impact on the performance of a system. Therefore, most distributed databases do not support transactions. A typical service scenario of a mailbox service is used as an example. Each email has the following attributes: a sender, a time, a status (read/unread), etc. When a new email is received by an email account, operations such as storing the content of the new email, modifying an inbox list and the number of unread messages, etc., need to be performed. In order to meet the requirements of different query and sorting conditions, the service also creates different indices for original data. Each time when a piece of original data and multiple pieces of index data are written, these write operations need to be completed in a transaction. However, in a scenario where a database does not support multi-row transactions, the service needs to implement various characteristics of the transaction. Referring to a schematic diagram of a write logic of a service layer shown in <FIG>, original data is updated according to data that is read. After one piece of data is written successfully, another piece of data is written, until all pieces of data are successfully written. However, this type of method needs to consider rollback processing for each write failure, and an infinite retry is needed when data that has been written is rolled back and deleted, having a relatively complicated service logic. In addition, if a crash occurs in a program of the service, no rollback can be performed for data that has been written, and thus transactional requirements cannot be met.

<CIT> discloses a system and method for processing a distributed transaction for an application. Conventionally transactions on critical data (e.g. financial information) are processed using a database architecture whereby a persistent database (typically a redundant disk array) comprises the master record. In cases where large amounts of data need to be accessed but absolute data integrity is less critical, for example search engines, processing is conducted on live in-memory data without all the data being backed up, which can be much faster but data can be lost when processors fail. There have been attempts to use data grid architectures with some backup to persistent stores for more important data but these have either introduced disk access bottlenecks or required manual intervention in the event of failure.

The present application provides a data transaction processing method to solve the problems that exist in existing technologies. In one aspect, the present application provides a data transaction processing method as defined in claim <NUM>. In another aspect, the present application provides a data transaction processing apparatus as defined in claim <NUM>.

Optional features are defined in the dependent claims.

The data transaction processing method provided in the present application receives an application request for a data operation on a target data partition sent by a client, creates a corresponding data transaction according to the application request, assigns a transaction identifier to the data transaction, returns the transaction identifier of the data transaction to the client, performs the data operation based on the target data partition according to the data operation sent by the client and carrying the transaction identifier, and processes the data transaction according to the transaction instruction sent by the client.

In the data transaction processing method, when processing a data transaction for a data operation on a target data partition performed by the client, a transaction identifier is allocated to the data transaction that is created, and the transaction identifier is returned to the client. The client submits a data operation carrying the transaction identifier, and a data operation is performed on the target data partition. Finally, the data transaction according is processed according to a transaction instruction sent by the client. As such, the data operation implements attributes of a transaction, and the transactional nature of the data operation is satisfied. At the same time, the service logic of data transactions implemented by the data transaction processing method is relatively simple, thus ensuring that data services have a good transactional nature.

A number of specific details are set forth in the following description in order to enable a full understanding of the present application. However, the present application can be implemented in many other ways different from those described herein. One skilled in the art can make similar generalizations without violating the content of the present application. Therefore, the present application is not limited by specific implementations disclosed below.

The present application provides a data transaction processing method. The present application also provides a data transaction processing apparatus, which are sequentially described in detail with reference to the accompanying drawings of the embodiments provided in the present application, and each step of the methods is described.

An embodiment of a data transaction processing method provided in the present application is given as follows.

Referring to <FIG>, a schematic diagram of a database transaction processing scenario provided by the present application is shown.

Step <NUM>: Receive an application request for performing a data operation on a target data partition sent by a client.

This step is a basis for subsequent data operations on the target data partition. Only through the application request for performing the data operation on the target data partition sent by the client, it is possible to obtain the permission to perform the data operation on the target data partition. The embodiments of the present application use a database transaction as an example for description, such as a database transaction of a distributed database (such as a NoSQL database) built on a distributed system. The distributed system refers to a logically unified database formed by connecting a plurality of physically dispersed data storage units through a network. Based on the distributed database, data fragmentation and load balancing can be used to achieve a seamless extension of the distributed database.

The target data partition refers to a data set that the client desires to operate. In the present embodiment, the target data partition refers to a partition key among partitions, and the partitions refer to basic scheduling units for load balancing in data storage. By horizontal expansion of data storage through partitions, performance and availability are ensured. Specifically, a primary key of a data table included in the database is composed of at least one primary key column in the data table, and the partition key refers to a single partition key composed of a first primary key column of the data table. Multiple partition keys may be included in one partition, and no overlap exists between these partition keys. In addition, in a specific implementation, the target data partition may also be a primary key column or a collection of multiple primary key columns other than the partition key in the data table. For example, the target data partition may also be a single partition key composed of any primary key column other than the first primary key column of the data table. Alternatively, the target data partition may also be a joint partition key composed of multiple primary key columns of the data table. Alternatively, the target data partition may also be a joint partition key composed of multiple partition keys. The present embodiment does not have any limitations thereon. The client embeds the partition key of the target data partition in the application request. In response to receiving the application request from the client, the partition key in the application request is obtained, and thereby a data set that the client desires to operate is determined. The data operation refers to specific operation on data under the partition key, such as adding a row of data, deleting a row of data, modifying a certain row, one or more values in certain rows of data, reading one or more pieces of certain data, etc..

In this step, the application request sent by the client for performing the data operation under the partition key, i.e., an application for a database transaction of the partition key, is received. For example, as shown in <FIG>, a database transaction for applying a partition key PK0 as <NUM> is received from a client corresponding to service <NUM>.

Step <NUM>: Create a corresponding data transaction according to the application request, and assign a transaction identifier to the data transaction.

The above step <NUM> receives an application request for performing a data operation under a partition key from the client, i.e., a database transaction for applying the partition key. This step creates a corresponding database transaction according to the application request, and allocates a transaction identifier for the database transaction.

The transaction identifier is an identification code allocated for a database transaction. A database transaction has one and only one transaction identifier, and transaction identifiers of each database transaction are different. More specifically, the transaction identifier may be in a form of a character string, or may be in a form of a number.

For example, as shown in <FIG>, after receiving a database transaction for applying a partition key PK0 as <NUM> from a client corresponding to service <NUM>, a database transaction <NUM> is created, and a corresponding transaction ID is assigned to the newly created database transaction <NUM> (a transaction identifier).

In this step, a transaction identifier is assigned to the database transaction, which provides a basis for the client to modify the database transaction. Since a server allocates different database transactions to clients corresponding to a plurality of services at the same time, it is necessary to determine a specific database transaction to be modified by the client according to the transaction identifier. At the same time, since the server allocates different database transactions to clients corresponding to a plurality of services at the same time, a partition key corresponding to the database transaction is locked, while assigning a transaction identifier to the database transaction, i.e., disallowing database transactions other than the database transaction to perform data operations on data under the partition key. For example, as shown in <FIG>, after a database transaction <NUM> sent by a client corresponding to service <NUM> locks a partition key PK0 of <NUM>, when a database transaction sent by a client corresponding to service <NUM> applies for the partition key PK0 of <NUM>, such application is failed.

A corresponding state is set for the partition key, which includes a locked state or an unlocked state. Once the application request received is an application request for performing a data operation under the current partition key, a state of the current partition key is updated to a locked state. If no application request for performing a data operation under the current partition key has been received, the state of the current partition key remains as an unlocked state.

Based thereupon, in a specific implementation, before creating the corresponding database transaction according to the application request and assigning the transaction identifier to the database transaction at this step, it is necessary to determine whether a partition key applied by the client is locked, i.e., determining whether the partition key is locked by determining whether a state of the partition key is an unlocked state. If the partition key is already locked, a response indicating an application failure is made for the application request for performing the data operation under the partition key sent by the client at step <NUM> above, and no database transaction is created, and no transaction identifier is assigned. If the partition key is not locked, this step is performed to create a corresponding database transaction according to the application request, and assign a transaction identifier to the database transaction.

Step <NUM>: Return the transaction identifier assigned to the data transaction to the client.

The above step <NUM> creates a corresponding database transaction according to the application request, and assigns a transaction identifier to the database transaction. At this step, the transaction identifier assigned to the database transaction at step <NUM> is returned to the client. For example, as shown in <FIG>, the transaction ID assigned to the database transaction <NUM> is returned to the client corresponding to the service <NUM>. The client corresponding to the service <NUM> receives the transaction ID of the database transaction <NUM>, indicating that the application is successfu I.

In addition, after returning the transaction identifier assigned to the database transaction to the client, a timeout detection mechanism may also be started. The timeout detection mechanism specifically determines whether an action instruction sent by the client is received within a certain time threshold range, i.e., whether an action instruction for processing the data transaction sent by the client described at step <NUM> below is received within the time threshold range. If not, a timeout is triggered, the database transaction is destroyed, and the transaction identifier is recycled. In other words, the database transaction is invalid, and the corresponding transaction identifier is also invalid. In a specific implementation, the time threshold range may be flexibly set according to an actual application scenario.

Step <NUM>: Perform the data operation based on the target data partition according to a data operation that is sent by the client and carries the transaction identifier.

This step performs the data operation based on the target data partition according to the data operation that is sent by the client and carries the transaction identifier. Specifically, in the present embodiment, multiple rows of data in the same target data partition can be modified at the same time. For example, as shown in <FIG>, the service <NUM> can carry the transaction ID corresponding to the newly created database transaction <NUM>, and modify multiple rows of data under the partition key PK0 of <NUM>. These modifications are placed in memory and are not taken into effect immediately, and are not visible to other database transactions. Moreover, if a machine where the server is located crashes down, these changes will be lost.

Step <NUM>: Process the data transaction according to a transaction instruction sent by the client.

At this step, prior to processing the data transaction according to the transaction instruction sent by the client, it is necessary to perform a step of receiving the transaction instruction for processing the database transaction sent by the client. Based on this, it is also possible to determine whether a database transaction corresponding to the transaction instruction exists after receiving the transaction instruction for processing the database transaction. If the database transaction exists, this step is performed, and the data transaction is processed according to the transaction instruction sent by the client. If the database transaction does not exist, prompt information is returned to the client indicating that no database transaction corresponding to the transaction instruction exists.

The transaction instruction described in the embodiments of the present application includes a transaction commit instruction or a transaction cancel instruction. These two transaction instructions are described separately below:.

In an actual application scenario, the server may interact with several clients at the same time, and different clients may submit different database transactions in a short period of time. These database transactions cannot be executed simultaneously. Therefore, a transaction queue is set, and the database transactions are submitted to the transaction queue. The database transactions are executed in order. Specifically, the transaction queue may be a linear table composed of database transactions. The transaction queue arranges the database transactions according to an order in which the database transactions are submitted, and sequentially reads the database transactions according to an order of arrangement.

For example, as shown in <FIG>, after receiving the transaction commit instruction sent by the client corresponding to the service <NUM> for the database transaction <NUM>, the database transaction <NUM> is submitted to the transaction queue. Thereafter, database transactions in the transaction queue are processed, and the database transaction <NUM> is read from the transaction queue. The data operation of the database transaction <NUM> is recorded in a corresponding transaction log, and the transaction log is finally stored in the memory.

In addition, after the aforementioned commit operation for the database transaction is completed, the database transaction is destroyed, and the transaction identifier corresponding to the database transaction is recovered. At the same time, the partition key corresponding to the database transaction is unlocked, i.e., allowing other database transactions to perform data operations on the data under the partition key, to ensure an isolation of the database transactions. Isolation is a security guarantee provided by database transactions for conflicts between concurrent transactions. Database transactions can provide different levels of separation between concurrently executed transactions through locking, to avoid executions of multiple concurrent transactions that manipulate the same shared object, which may cause an abnormal situation.

<NUM>) The transaction instruction sent by the client is a transaction cancel instruction:
This step processes the data transaction according to the transaction instruction sent by the client, and is specifically implemented in the following manner:
deleting the database transaction, and recovering the transaction identifier corresponding to the database transaction. Since the database transaction is not actually executed, the database transaction is invalidated, thus ensuring the atomicity of the database transaction.

In addition, in a specific implementation, the transaction instruction sent by the client for processing the database transaction further includes a transaction rollback instruction. The database transaction is rolled back before the database transaction is committed, the modification of the database transaction that was previously performed is discarded, and the processing of the database transaction is terminated.

In a specific implementation, the data transaction processing method provided in the present application may also be implemented based on a platform of a distributed database deployed in a cloud computing environment. The platform of the distributed database is configured with a data access interface used for accessing the distributed database (such as a NoSQL database). When a client corresponding to a service wants to use the NoSQL database for service data processing, the client submits a database transaction that is based on a NoSQL database partition key application to the server by calling the data access interface. The server obtains the database transaction that is based on the NoSQL database-based partition key application submitted by the client corresponding to the service through the data access interface, and performs corresponding processing. At the same time, the client corresponding to the service also submits a transaction instruction for processing the database transaction to the server through the data access interface. The server obtains the transaction instruction through the data access interface, and processes the database transaction according to the transaction instruction.

In summary, in the data transaction processing method provided in the present application, when processing a database transaction on which the client performs a data operation under the partition key, a transaction identifier is allocated to the created database transaction, and the transaction identifier is returned to the client. The client performs the data operation under the partition key by submitting the data operation carrying the transaction identifier, and processing on the database transaction is finally performed according to a transaction instruction sent by the client. This therefore enables the data operation to implement transactional attributes, and satisfy the transactional nature of the data operation. At the same time, the service logic of the data transaction processing method for implementing data transactions is relatively simple, ensuring data services to have a good transactional nature.

An embodiment of a data transaction processing apparatus provided in the present application is given as follows.

In the foregoing embodiments, a data transaction processing method is provided. Correspondingly, the present application also provides a data transaction processing apparatus, which will be described below with reference to the accompanying drawings.

Referring to <FIG>, a schematic diagram of an embodiment of a data transaction processing apparatus provided by the present application is shown.

Since the apparatus embodiment is basically similar to the method embodiment, a description thereof is relatively simple. Related parts can be referenced to a corresponding description of the method embodiment provided above. The apparatus embodiment described below is only schematic.

The present application provides a data transaction processing apparatus, which includes an application receiving unit <NUM> configured to receive an application request sent by a client for performing a data operation on a target data partition; a data transaction creating unit <NUM> configured to create a corresponding data transaction according to the application request, and assign a transaction identifier to the data transaction; a transaction identifier returning unit <NUM> configured to return the transaction identifier assigned to the data transaction to the client; a data operation submitting and executing unit <NUM> configured to execute the data operation based on the target data partition according to the data operation submitted by the client and carrying the transaction identifier; a data transaction processing unit <NUM> configured to process the data transaction according to a transaction instruction sent by the client.

Optionally, the target data partition includes a partition key in a data table included in a database.

Correspondingly, the data transaction includes a database transaction.

Optionally, a primary key of the data table is composed of at least one primary key column in the data table.

The partition key includes a single partition key composed of a first primary key column of the data table.

Optionally, the transaction instruction includes a transaction commit instruction or a transaction cancel instruction.

Optionally, if the transaction instruction sent by the client is the transaction commit instruction, the data transaction processing unit <NUM> includes a submission subunit configured to submit the database transaction to a transaction queue; and a transaction log recording subunit configured to read the database transaction from the transaction queue, create a transaction log corresponding to the database transaction, and record a data operation of the database transaction in the transaction log.

Optionally, the data transaction processing unit <NUM> includes a transaction log storage subunit configured to store the transaction log in a preset data storage space.

Optionally, the data transaction processing unit <NUM> includes a first transaction recovery subunit configured to delete the database transaction and recover the transaction identifier corresponding to the database transaction.

Optionally, if the transaction instruction sent by the client is the transaction cancel instruction, the data transaction processing unit <NUM> includes a second transaction recovery subunit configured to delete the database transaction and recover the transaction identifier of the database transaction.

Optionally, the data transaction processing apparatus includes a transaction instruction receiving unit configured to receive the transaction instruction sent by the client for processing the database transaction.

Optionally, the data transaction processing apparatus includes a database transaction determination unit configured to determine whether a database transaction corresponding to the transaction instruction exists, and run a prompt information sending unit if not; and the prompt information sending unit configured to return prompt information indicating that no database transaction corresponding to the transaction instruction exists to the client.

Optionally, a state of the partition key includes at least one of the following: a locked state and an unlocked state.

If the received application request is an application request for performing a data operation under the partition key, a state of the partition key is updated to a locked state.

Optionally, the data transaction processing apparatus includes a partition key state determination unit configured to determine whether a state of the partition key is an unlocked state, and run the data transaction creation unit <NUM> if not.

Optionally, the database includes a logically unified distributed database formed by connecting a plurality of physically dispersed data storage units through a network.

Optionally, the data transaction processing apparatus operates based on a platform of a distributed database deployed in a cloud computing environment, and the platform of the distributed database provides a data access interface for accessing the distributed database, and receives the application request sent by the client for performing a data operation under a partition key of the distributed database through the data access interface, and/or receives the transaction instruction sent by the client for processing the database transaction through the data access interface.

An embodiment of another data transaction processing method provided in the present application is given as follows.

In the foregoing embodiments, a data transaction processing method is provided. In addition, the present application provides another data transaction processing method that cooperates with the above data transaction processing method, which is described below with reference to the accompanying drawings.

Referring to <FIG>, a processing flowchart of an embodiment of another data transaction processing method provided in the present application is shown. Referring to <FIG>, a schematic diagram of a database transaction processing scenario provided in the present application is shown.

Since another data transaction processing method provided in the present application cooperates with the above-mentioned data transaction processing method embodiment, a description thereof is relatively simple. For reading this embodiment, references are made to the corresponding description of the above data transaction processing method embodiment.

An example of an electronic device provided in the present application is given as follows.

In the above embodiments, a data transaction processing method is provided. In addition, the present application also provides an electronic device for implementing the data transaction processing method, which is described below with reference to the accompanying drawings.

Referring to <FIG>, a schematic diagram of an electronic device according to the present embodiment is shown.

An embodiment of another electronic device provided in the present application is given as follows.

In the above embodiments, another data transaction processing method is provided. In addition, the present application also provides an electronic device for implementing the other data transaction processing method provided by the present application, which is described below with reference to the accompanying drawings.

Referring to <FIG>, a schematic diagram of another electronic device according to the present embodiment is shown.

Although the present application is disclosed above using preferred embodiments, these preferred embodiments not intended to limit the present application. One skilled in the art can make possible changes and modifications without departing from the scope of the present application. The scope of protection shall be subject to the scope defined by the claims of the present application.

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

The memory may include a form of computer readable media such as a volatile memory, a random access memory (RAM) and/or a non-volatile memory, for example, a read-only memory (ROM) or a flash RAM. The memory is an example of a computer readable media.

The computer readable media may include a volatile or non-volatile type, a removable or non-removable media, which may achieve storage of information using any method or technology. The information may include a computer readable instruction, a data structure, a program module or other data. Examples of computer storage media include, but 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), electronically erasable programmable read-only memory (EEPROM), quick flash memory or other internal storage technology, compact disk read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassette tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission media, which may be used to store information that may be accessed by a computing device. As defined herein, the computer readable media does not include transitory media, such as modulated data signals and carrier waves.

Claim 1:
A data transaction processing method comprising:
receiving an application request from a client to perform a data operation in a target data partition, the application request including a partition key corresponding to the target data partition and wherein a state can be set for the partition key which includes a locked state or an unlocked state;
determining whether the partition key corresponding to the target data partition received in the application request is locked;
in response to determining that the partition key corresponding to the target data partition is in an unlocked state, creating a corresponding data transaction according to the application request, assigning a transaction identifier to the data transaction, and updating the partition key to a locked state;
in response to determining that the partition key corresponding to the target data partition is in a locked state, making a response indicating an application failure for the application request for performing the data operation under the partition key received from the client, no database transaction is created, and no transaction identifier is assigned;
in response to determining that a transaction identifier is assigned, returning the transaction identifier that is assigned to the data transaction to the client;
receiving a data operation carrying the transaction identifier from the client for performing the data operation on the target data partition;
performing the data operation based on the target data partition according to the data operation that carries the transaction identifier and is sent by the client;
receiving a transaction instruction for processing the data transaction from the client based on the transaction identifier prior to performing the data operation; and
processing the data transaction according to the transaction instruction sent by the client, wherein the transaction instruction includes a transaction commit instruction or a transaction cancel instruction.