Method and apparatus for updating a database by using two-phase commit distributed transactions - Patents.com

Abstract

To provide a method for updating databases by using two-phase commit distributed transactions.SOLUTION: A method is applied to a coordinator, and includes the steps of: transmitting a phase 1 preparation request message to each participant for terminating a current transaction used to update a target database record; and after receiving write lock prior release requests transmitted by all the participants, returning a write lock prior release response to each participant in order to instruct each participant to unlock the participant's target database record. After a participant has successfully written a log of update calculation of the current transaction to a log buffer, the write lock prior release request is transmitted by the participant.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] The present specification relates to the field of network communication technology, and more particularly to a method and apparatus for updating a database by using two-phase commit distributed transactions. [Background technology]

[0002] Transactions provide a mechanism by which all operations involved in an activity can be combined into an atomic unit of execution. All operations that make up a transaction can be committed only if all operations can be executed successfully. Failure of any of these operations causes the entire transaction to be aborted. In a distributed transaction, all parties involved in the transaction processing are usually located on different network nodes. The two-phase commit (2PC) protocol is widely used to satisfy the atomicity, consistency, isolation, and durability (ACID) properties of distributed transactions.

[0003] Large-scale websites often use distributed transactions to achieve high-speed concurrent access to databases. In some application scenarios, such as "seckill" activities, intensive updates to hot rows occur within a very short time period. The performance of "seckill" is closely related to the user experience. How to improve the concurrent performance of distributed transactions used to update hot rows has become particularly important. Summary of the Invention [Means for solving the problem]

[0004] In view of the above, this specification provides a method for updating a database by using a two-phase commit distributed transaction, the method being applied to a participant, and includes the steps of: according to an instruction for updating a target database record in a current transaction, adding a write lock to the target database record, and then executing the update operation according to the instruction; recording a predecessor transaction of the current transaction in the transaction information record using another transaction in the transaction information record whose state is to release the write lock beforehand and whose update target involves the target database record as the predecessor transaction of the current transaction; writing a log of the update operation of the current transaction to a log buffer after receiving a phase 1 prepare request message sent by a coordinator, and sending a write lock pre-release request to the coordinator after the write is successful; Therefore, the method includes the steps of releasing the write lock after receiving the returned write lock pre-release response and setting the state of the current transaction in the transaction information record to write lock pre-release; sending a phase 1 prepare response message indicating prepare success to the coordinator after all preceding transactions of the current transaction have entered the committed state after successfully storing the log of the update operation of the current transaction in the log buffer, or sending a phase 1 prepare response message indicating prepare failure to the coordinator after any preceding transaction of the current transaction has entered the aborted state; and setting the current transaction in the transaction information record to the committed state or the aborted state based on the execution result of the current transaction in phase 2.

[0005] This specification provides a method for updating a database by using a two-phase commit distributed transaction, the method includes the steps of: applying to a coordinator, sending a phase 1 prepare request message to each participant to terminate a current transaction being used to update a target database record; and returning a write lock pre-release response to each participant to instruct each participant to unlock the target database record of the participant after receiving write lock pre-release requests sent by all participants, wherein the write lock pre-release request is sent by the participant after the participant successfully writes a log of the update operation of the current transaction to a log buffer.

[0006] The present specification further provides an apparatus for updating a database by using a two-phase commit distributed transaction, the apparatus including: an update operation execution unit, applied to a participant, configured to add a write lock to the target database record according to an instruction for updating the target database record in the current transaction and then execute the update operation according to the instruction; a previous transaction discovery unit, configured to record a previous transaction of the current transaction in the transaction information record using another transaction in the transaction information record whose state is to release the write lock in advance and whose update target involves the target database record as a previous transaction of the current transaction; a write lock release request unit, configured to write a log of the update operation of the current transaction to a log buffer after receiving a phase 1 prepare request message sent by the coordinator, and to send a write lock pre-release request to the coordinator after the write is successful; a write lock pre-release unit configured to release the write lock after receiving the returned write lock pre-release response and set the state of the current transaction in the transaction information record to "previously release the write lock"; a first prepare response sending unit configured to send a phase 1 prepare response message of prepare success to the coordinator after all preceding transactions of the current transaction have entered a committed state or to send a phase 1 prepare response message of prepare failure to the coordinator after any preceding transaction of the current transaction has entered an aborted state after successfully storing logs of update operations of the current transaction in the log buffer; and a commit-abort state unit configured to set the current transaction in the transaction information record to a committed state or an aborted state based on the execution result of the current transaction in phase 2.

[0007] This specification provides an apparatus for updating a database by using a two-phase commit distributed transaction, the apparatus including: a prepare request sending unit, applied to a coordinator, configured to send a phase 1 prepare request message to each participant to terminate a current transaction being used to update a target database record; and a write unlock response unit, configured to return a write lock pre-release response to each participant to instruct each participant to unlock the target database record of the participant after receiving write lock pre-release requests sent by all participants, wherein the write lock pre-release request is sent by a participant after the participant successfully writes a log of the update operation of the current transaction to a log buffer.

[0008] The present specification provides a computer device including a memory and a processor, wherein the memory stores a computer program that can be executed by the processor, and when the processor executes the computer program, steps of a method applied to participants to update a database by using two-phase commit distributed transactions are performed.

[0009] The present specification provides a computer device including a memory and a processor, wherein the memory stores a computer program that can be executed by the processor, and when the processor executes the computer program, steps of a method applied to a coordinator to update a database by using two-phase commit distributed transactions are performed.

[0010] The present specification provides a computer-readable storage medium storing a computer program, which, when executed by a processor, performs steps of a method applied to participants to update a database by using two-phase commit distributed transactions.

[0011] The present specification further provides a computer-readable storage medium storing a computer program, which, when executed by a processor, performs steps of a method applied to a coordinator for updating a database by using two-phase commit distributed transactions.

[0012] As can be learned from the above technical solution, in the implementation form of this specification, in the prepare phase of phase 2 commitment, after the log of the update operation is successfully written to the log buffer, the participant sends a write lock pre-release request to the coordinator. After receiving a write lock pre-release request from each participant of the distributed transaction, the coordinator returns a write lock pre-release response, so that each participant pre-releases the write lock. In this way, the lock time of the target database record is significantly reduced, so that another transaction used to update the same target database record can be executed in advance, thereby improving the performance of parallel processing. In addition, each participant maintains the status of the current transaction and the preceding transaction of the current transaction in a transaction information record, and returns a phase 1 prepare success or failure message to the coordinator after the preceding transaction enters a committed or aborted state, thereby implementing the ACID property of the distributed transaction. [Brief explanation of the drawings]

[0013] [Figure 1] FIG. 1 is a schematic diagram showing the interactive procedure between a coordinator and a participant in a 2PC protocol. [Figure 2] FIG. 1 is an exemplary sequence diagram illustrating multiple participants updating a database record simultaneously in existing technology. [Figure 3] 1 is a flowchart illustrating a method applied to a participant to update a database by using a two-phase commit distributed transaction, according to an implementation of the present specification. [Figure 4] 10 is a flowchart illustrating a method applied to a coordinator to update a database by using a two-phase commit distributed transaction, according to an implementation of the present specification. [Figure 5] FIG. 2 is a schematic diagram illustrating the interactive procedure between the coordinator and participants after the end of a transaction has been initiated in the application example of the present specification. [Figure 6] FIG. 2 is an exemplary sequence diagram illustrating multiple participants updating database records simultaneously in an example application of the present specification. [Figure 7] FIG. 1 is a hardware structural diagram illustrating a device implementing an embodiment of the present disclosure. [Figure 8] 1 is a logical structure diagram illustrating an apparatus applied to a participant to update a database by using a two-phase commit distributed transaction according to an implementation of the present specification. [Figure 9] 1 is a logical structure diagram illustrating an apparatus applied to a coordinator to update a database by using a two-phase commit distributed transaction according to an implementation of the present specification. DETAILED DESCRIPTION OF THE INVENTION

[0014] For a distributed transaction used to update a database record (the updated database record is called the target database record), the coordinator determines which participants are executing the current transaction and then starts the execution of the current transaction. The coordinator sends instructions to each participant for updating the target database record. For a participant, the execution process includes the following four steps:

[0015] Step A1: A participant parses a computation command for updating a database record to generate an execution plan that is used to execute the computation command.

[0016] Step A2: Add a write lock to the target database record, and perform an update operation on the target database record according to the execution plan, where the update operation on the database record may be at least one of modifying, deleting, or adding a data item in the target database record, or may be at least one of adding or deleting an entry in the database record, or may be another operation that needs to be performed exclusively on the target database record.

[0017] When the initiator of the current transaction instructs the coordinator to terminate the transaction (in other words, when the initiator of the current transaction commits the current transaction, where commitment in this specification refers to terminating the transaction to distinguish it from phase 2 commitment in 2PC), the coordinator starts the 2PC procedure and sends a phase 1 prepare request message to each participant. 2PC is a type of distributed consensus protocol used to commit transactions. The protocol includes two phases of operation, the first phase is the prepare phase and the second phase is the commit / abort phase. The interactive procedure between the coordinator and participants in the 2PC protocol is shown in Figure 1.

[0018] For the participant, Step A3: After receiving the phase 1 prepare request message, the participant writes the log of the update operation into the log buffer.

[0019] Step A4: Maintain the log of the update operations in the log buffer, i.e., permanently store the log written to the log buffer on a medium. For example, a locally stored log file is written to a log file on a local hard drive. For another example, in a scenario where the log file has multiple backup files, the log of the update operations in the log buffer is synchronized with the multiple backup files. After log persistence is successful, the participant returns a phase 1 prepare response message indicating successful preparation ("Ready") to the coordinator. If not all operations in steps A1 to A3 are successfully executed or log persistence fails, the participant returns a phase 1 prepare response message indicating unsuccessful preparation ("Not Prepared") to the coordinator. The participant performs a two-phase commit or abort based on the commit message or abort message sent by the coordinator in phase 2, and writes the commit log or abort log of the current transaction.

[0020] After completing step A4, the participant unlocks the target database record.

[0021] In the above four steps, the lock time of each participant on the target database record is from step A2 to step A4. The longest time-consuming operations are log persistence in step A4 and the synchronization process performed when the transaction is completed according to the 2PC protocol. Especially for large-scale websites, their log files usually have multiple backups, often located in different cities. Due to unavoidable transmission delays, log persistence takes a very long time. For centralized transactions and parallel transactions used to update the same target database record, performance is significantly affected because steps A2 to A4 on subsequent transactions can only be executed after the target database record is unlocked for the previous transaction. Assuming that transactions T1, T2, and T3 use the same row Row1 in the database as the target of the update operation, the execution sequence of T1, T2, and T3 at maximum possible concurrency is shown in Figure 2.

[0022] The implementation of this specification provides a method for updating a database by using a two-phase commit distributed transaction. When a participant executes a phase 1 prepare request message in the prepare phase, the participant writes a log of the update operation to a log buffer in step A3 and then sends a write lock pre-release request to the coordinator. After receiving the write lock pre-release requests from all participants, the coordinator returns a write lock pre-release response to each participant. The participant unlocks the target database record based on the write lock pre-release response and does not wait for log persistence and the synchronization process in the 2PC protocol in step A4. Therefore, the lock time for the target database record is significantly reduced, and parallel processing performance is improved. In addition, based on the transaction state of each participant and the dependency between the preceding transaction and the succeeding transaction maintained in the transaction information record, the ACID property of the distributed transaction is not affected when the transaction is aborted.

[0023] In the implementation of the present specification, in the distributed system, the coordinator can communicate with one or more participants via a network. The coordinator or participants can run on any device with computing and storage capabilities, such as a mobile phone, a tablet computer, a personal computer (PC), a notebook computer, or a server, or various functions of the coordinator or participants in the implementation of the present specification can be implemented by logical nodes running on two or more devices. In addition, the coordinator and one or more participants can be located on the same physical device. This is not a limitation herein.

[0024] In the implementation herein, the procedure by which the method for updating a database by using 2PC distributed transactions is applied to a participant is shown in Figure 3, and the procedure by which the method is applied to a coordinator is shown in Figure 4. Distributed transactions are used to update database records.

[0025] For the participant, step S310: according to the instruction for updating the target database record in the current transaction, add a write lock to the target database record and then execute the update operation according to the instruction.

[0026] As described above, after starting the execution of the current transaction, the coordinator sends an instruction to each participant to update the target database record. The participant determines the target database record to be updated according to the instruction, adds a write lock to the target database record, and after successfully adding the write lock, executes the update operation specified in the instruction on the target database record.

[0027] In implementations herein, a database record may be a table, a page, a row, etc. in a database, or an entry or combination of entries stored in another database, although this is not a limitation herein.

[0028] For the participant, step S320: record the predecessor transaction of the current transaction in the transaction information record using another transaction in the transaction information record whose state is to release the write lock beforehand and whose update target involves the target database record as the predecessor transaction of the current transaction.

[0029] Each participant maintains an independent transaction information record, which is used to record various information of the distributed transaction executed by the participant, including, but not limited to, the transaction identifier, the transaction status, etc. The transaction status includes the execution result in phase 2 (specifically, commit or abort) and may further include the prepare result in phase 1 (specifically, prepare successfully or prepare failed). In the implementation form herein, the predecessor transaction of the current transaction is recorded in the transaction information record, and the state of releasing the write lock beforehand is added to the transaction status.

[0030] When starting to execute a transaction, a participant writes information about the transaction to a transaction information record. In the implementation form herein, after determining the target database record according to the received instruction, the participant searches the transaction information record for another transaction whose update operation involves the target database record (i.e., the database to be updated when the update operation is executed includes at least a portion of the target database record) and whose state is to release the write lock beforehand. If such a transaction is found, the transaction is recorded in the transaction information record as a predecessor transaction of the current transaction. The current transaction is a successor transaction of each predecessor transaction. In some application scenarios, for each predecessor transaction of the current transaction, the current transaction may further be recorded in the transaction information record as a successor transaction of the predecessor transaction.

[0031] In the implementation herein, a current transaction can have one or more prior transactions, or no prior transactions.

[0032] The write lock added to the target database record may be any lock that can prevent another transaction from performing an update operation on the target database record, such as mutual exclusion locks and exclusive locks, collectively referred to as write locks in the implementations herein.

[0033] For the coordinator, Step S410: send a phase 1 prepare request message to the participant to terminate the current transaction used to update the target database record.

[0034] After receiving a command to terminate the transaction from the initiator of the current transaction, the coordinator starts the 2PC protocol and sends a Phase 1 prepare request message for the current transaction to each participant.

[0035] For the participant, step S330: after receiving the phase 1 preparation request message sent by the coordinator, write the log of the update operation of the current transaction to the log buffer, and after the write is successful, send a write lock pre-release request to the coordinator.

[0036] If a participant fails to write the log of the update operation of the current transaction to the log buffer, the participant does not send a write lock pre-release request to the coordinator.

[0037] For the coordinator, step S420: after receiving the write lock pre-release requests sent by all participants, return a write lock pre-release response to each participant to instruct each participant to unlock the participant's target database record, and the write lock pre-release request is sent by the participant after the participant successfully writes the log of the update operation of the current transaction to the log buffer.

[0038] For the participant, step S340: release the write lock after receiving the write lock pre-release response returned by the coordinator, and set the state of the current transaction in the transaction information record to release the write lock in advance.

[0039] The coordinator receives the write lock pre-release requests sent by the participants. If the coordinator successfully collects the write lock pre-release requests sent by all participants in a transaction for one transaction, the coordinator returns a write lock pre-release response to each participant. The write lock pre-release response is used to instruct each participant in the transaction to unlock the target database record in advance, and the participants in the transaction do not need to unlock the target database after step A4 is completed.

[0040] When the coordinator does not receive a write lock pre-release request sent by one or more participants, the coordinator does not perform any processing.

[0041] When a participant receives the write lock pre-release response sent by the coordinator, the participant unlocks the target database record regardless of whether log persistence is completed, and records the state of the current transaction as pre-releasing the write lock in the transaction information record.

[0042] If the participant does not receive the write lock pre-release response sent by the coordinator, the participant unlocks the target database record after step A4 is completed.

[0043] For the participant, step S350: after successfully storing the log of the update operation of the current transaction in the log buffer, send a phase 1 prepare response message indicating successful preparation to the coordinator after all preceding transactions of the current transaction have entered the committed state, or send a phase 1 prepare response message indicating unsuccessful preparation to the coordinator after any preceding transaction of the current transaction has entered the aborted state.

[0044] After completing the log of the update operation in the log buffer, if the current transaction has one or more preceding transactions, the participant queries the state of each preceding transaction in the transaction information record. The participant sends a phase 1 prepare response message of prepare success to the coordinator after all preceding transactions enter the committed state, or the participant sends a phase 1 prepare response message of prepare failure to the coordinator after any preceding transaction enters the aborted state.

[0045] If the current transaction has no preceding transaction, the participant sends a phase 1 prepare response message indicating successful preparation to the coordinator after successfully storing the log of the update operation of the current transaction in the log buffer. Similar to the existing 2PC protocol, if the participant fails in any one of steps A1 to A3 or fails to store the log of the update operation of the current transaction, the participant sends a phase 1 prepare response message indicating unsuccessful preparation to the coordinator.

[0046] For the participant, step S360: based on the execution result of the current transaction in phase 2, set the current transaction in the transaction information record to the committed state or the aborted state.

[0047] In phase 2 (commit / abort phase), if the messages received by the coordinator from all participants are phase 1 prepare response messages indicating successful prepare, the coordinator sends a commit message to each participant. If any participant returns a prepare failure, the coordinator sends an abort message to all participants. Based on the commit or abort message received from the coordinator, the participant commits or aborts the current transaction in phase 2, and writes the state of the current transaction as committed or aborted in the transaction information record.

[0048] In the implementation of this specification, after transaction TA preliminarily releases the write lock, another transaction (denoted as transaction TS) can add a write lock to the same target database record to perform an update operation. When transaction TS adds a write lock, if the state of transaction TA recorded in the transaction information record is not committed or aborted but is to preliminarily release the write lock, it indicates that whether transaction TA's update operation on the target database record will ultimately be performed is still pending. If transaction TA is ultimately aborted, it is highly likely that the target database record before being updated by using transaction TS is incorrect (in other words, dirty data has been updated), and transaction TS also needs to be aborted. The success or failure of transaction TS depends on the final execution result of transaction TA. Therefore, in the implementation of this specification, the dependency between transaction TS and transaction TA is indicated by using transaction TA as the predecessor transaction of transaction TS and transaction TS as the successor transaction of transaction TA, and this dependency is recorded in the transaction information record. The success or failure of the prepare of the successor transaction is determined after the final state of the successor transaction's predecessor transaction is determined, and then a phase 1 prepare response message is sent to the successor transaction's coordinator.

[0049] A predecessor transaction is discovered by a successor transaction. Specifically, before performing an update operation on a target database record, the successor transaction searches the transaction information record for a predecessor transaction whose update operation involves the target database record and whose state is to release the write lock beforehand. The dependency between the successor transaction and the predecessor transaction is recorded in the transaction information record. After the two-phase commitment / abortion on each transaction in 2PC is completed, the state of the current transaction is updated in the transaction information record. In this way, the successor transaction of the current transaction can decide to send a phase 1 prepare response message of prepare success or prepare failure to the coordinator in time.

[0050] In some application scenarios, various information about transactions may be recorded by using entries in transaction information records (e.g., rows in a database table). In these application scenarios, after a subsequent transaction discovers a predecessor transaction of the current transaction, when the predecessor transaction of the current transaction is recorded in the transaction information record, the status of each predecessor transaction and each predecessor transaction may be recorded in the entry of the current transaction, which is written in the entry of each predecessor transaction of which the current transaction is a successor. When used to update the status of the current transaction in the transaction information record based on the execution result in the commit / abort phase, each transaction not only updates the status of the current transaction in the entry of the current transaction, but also updates the status of the current transaction in the entry of each successor transaction to a committed state or an aborted state if the current transaction has a successor transaction. In this way, when waiting for the final status of the predecessor transaction, the subsequent transaction only needs to query the entry of the current transaction in the transaction information record and does not need to repeatedly search the entry of each predecessor transaction, thereby reducing resource occupation and accelerating response speed.

[0051] In the process of the implementation of the present specification, if a preceding transaction consumes a relatively long time in step A4, there may be multiple layers of cascading subsequent transactions (where cascading means that the preceding transaction of the current transaction is a successor of another transaction). In fact, operations that take longer than normal operations are more likely to fail. In this way, when a preceding transaction with multiple layers of cascading subsequent transactions is aborted, all layers of subsequent transactions that depend on the preceding transaction must be aborted. This not only hinders the improvement of parallel processing performance, but also affects the stability of the distributed system.

[0052] To reduce the likelihood of the above situation occurring, after receiving the write lock pre-release requests sent by all participants, the coordinator can generate a commit timestamp for the current transaction and add the generated commit timestamp to the write lock pre-release response to be sent to each participant. The commit timestamp is used to measure the start time of log persistence on the participants of the current transaction. The participants record the commit timestamp of the current transaction in their transaction information records. When the phase 1 prepare request message is executed, the commit timestamps of all predecessor transactions of the subsequent transaction can be found in the transaction information records, and the likelihood of multiple layers of successive abortions occurring is reduced by using one or two of the following implementations.

[0053] In a first implementation, before a participant executes an update operation on a target database record in accordance with the instruction, a difference between a timestamp of the current update operation and a commit timestamp of each preceding transaction of the current transaction is calculated. If a difference between the timestamp of the current update operation and a commit timestamp of a preceding transaction or several preceding transactions reaches or exceeds a first threshold, the participant executes the update operation in accordance with the instruction after the preceding transaction or the preceding transactions enter a committed or aborted state.

[0054] In a second implementation, before a participant writes a log of an update operation of a current transaction to a log buffer, a difference is calculated between a timestamp at which the log of the update operation of the current transaction is written to the log buffer and a commit timestamp of each preceding transaction of the current transaction. If the difference between the timestamp and the commit timestamp of a preceding transaction or several preceding transactions reaches or exceeds a second threshold, the participant writes a log of the update operation of the current transaction to the log buffer after the preceding transaction or the preceding transactions enter a committed state or an aborted state.

[0055] In the above two implementation forms, since the exact start time of each participant differs from the start time measured by the commit timestamp when the participants perform log persistence, the coordinator can use an approximate time as the commit timestamp. For example, the coordinator can use the time when the coordinator receives the write lock pre-release requests sent by all participants as the commit timestamp, the time when the coordinator sends the write lock pre-release response as the commit timestamp, or another time as the commit timestamp. This is not limited in this specification. In one example, each participant can record the timestamp at which it writes a log of update operations of the current transaction to the log buffer and encapsulate the timestamp in the write lock pre-release request to send to the coordinator. After receiving the write lock pre-release requests sent by all participants, the coordinator uses the latest timestamp among all the write lock pre-release requests at which it writes a log of update operations to the log buffer as the commit timestamp of the current transaction.

[0056] In addition, the first threshold and the second threshold may be determined with reference to factors such as the duration required by log persistence in an actual application scenario and the tolerance for consecutive aborts, which are not limited herein. For example, in a scenario where a log file has backups in different locations, several times (e.g., 2 to 4 times) the normal transmission delay between the two locations may be used as the first threshold or the second threshold.

[0057] When a device where a participant is located is restarted due to an outage, the status of a committed or aborted transaction can be recovered in the recovery process by using the log. For transactions that have not yet been committed or aborted, the procedure in 2PC needs to be continued until the transaction is committed or aborted. In the recovery process, if a transaction that has not yet been committed or aborted has a predecessor transaction, the execution result of the subsequent transaction can be determined only by referring to the commit / abort status of the predecessor transaction. For a primary-secondary backup application scenario, the situation is similar to that after a primary-secondary switch. To solve the problem of data accuracy in the recovery process, each participant can maintain the status of the current transaction's predecessor transactions in the transaction information record (e.g., writing all predecessor transactions of the current transaction to the redo log) and the status of the current transaction. In this way, after a restart due to an outage or primary-secondary switch, the recovery process can be performed based on the dependency between the status of the transaction and the predecessor transaction. If the prior transaction is aborted, then during the recovery process, the subsequent transaction can learn from the retained information that the prior transaction was aborted and that the current transaction was not committed based on dirty data.

[0058] Additionally, for a read-only transaction used to access a target database record, the read-only transaction is allowed to read the results of the committed transaction's updates to the target database record, and updates performed on the target database record by using a transaction that has not yet been committed or aborted can be ignored. In this way, abortion of the read-only transaction can be avoided, and the stability of the distributed system is promoted.

[0059] As can be seen, in the implementation of this specification, in the prepare phase, after the log of the update operation is successfully written to the log buffer, the participant sends a write lock pre-release request to the coordinator. After receiving a write lock pre-release request from each participant of the distributed transaction, the coordinator returns a write lock pre-release response, so that each participant pre-releases the write lock and does not wait for the log persistence process. In this way, the lock time of the target database record is reduced, so that another transaction used to update the same target database record can be executed in advance, thereby improving the performance of parallel processing. In addition, the transaction state of each participant and the dependency between the preceding transaction and the subsequent transaction are maintained in the transaction information record, so that the ACID property of the distributed transaction is not affected when the transaction is aborted.

[0060] The above describes specific implementations of the present specification. Other implementations are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the implementations and still achieve desirable results. In addition, the processes described in the accompanying figures do not necessarily require the particular illustrated order or sequential order to achieve desirable results. In some implementations, multitasking and parallel processing may also be possible or advantageous.

[0061] In an example application herein, a large business website uses a distributed system to update multiple related databases as deals occur. "Second-run" activity poses challenges to the performance of concurrent updates to hot rows in the database. The business website implements distributed transactions used to update the hot rows based on the 2PC protocol by using the following method: After the completion of a transaction is initiated, the interactive procedure between the coordinator and participants can be seen in FIG. 5.

[0062] Each participant maintains a transaction information registration table (transaction information record). Each transaction in the transaction information registration table corresponds to a row of the record. Data items in this row of the record include the identifier of the current transaction, the commit timestamp of the current transaction, the identifier of the preceding transaction of the current transaction, the status of the preceding transaction of the current transaction, the identifier of the succeeding transaction of the current transaction, etc.

[0063] A distributed transaction log file for a business website has three backups located in three different cities. The longest transmission delay between the three cities is 100 milliseconds (ms). In this application example, the first and second thresholds are both set to 200 ms.

[0064] After a distributed transaction used to update a hot row begins, the coordinator sends each participant an instruction to update the target database record, where the instruction includes an identifier for the current transaction and specifies the database row to be updated by each participant and the specific update operation for this row.

[0065] The participant receives an instruction to update the target database record and parses the target to be updated from the instruction. The participant queries a transaction information registration table maintained by the participant and uses another transaction in the transaction information registration table whose state is to release the write lock beforehand and whose update target is the target row as the predecessor transaction of the current transaction. The participant writes an entry (row of record) for the current transaction to the transaction information registration table, where the entry includes an identifier of the current transaction, an identifier of each predecessor transaction of the current transaction, and the state of each predecessor transaction (which is currently to release the write lock beforehand), and writes the identifier of the current transaction to the entry of each predecessor transaction in the transaction information registration table as the successor transaction of the predecessor transaction.

[0066] The participant adds a write lock to the target row. The participant queries the commit timestamp of each preceding transaction from the transaction information registration table, obtains the timestamp of the current update operation on the target row, and calculates the difference between the two timestamps. If the difference exceeds 200 ms, the participant pauses or waits. The participant executes the specific update operation on the target row after the preceding transaction in the transaction information registration table with a difference exceeding 200 ms enters the commit or abort state. If neither difference reaches 200 ms, the participant executes the specific update operation on the target row.

[0067] After the instructions for the current transaction are completed, the coordinator sends a phase 1 prepare request message for the current transaction to each participant.

[0068] A participant receives the phase 1 prepare request message for the current transaction, obtains the timestamp for writing the log of the current update operation to the log buffer, and calculates the difference between the timestamp for writing the log of the current update operation to the log buffer and the commit timestamp of each preceding transaction. If the difference exceeds 200 ms, the participant pauses or waits. After a preceding transaction in the transaction information registration table with a difference exceeding 200 ms enters the commit or abort state, the participant writes the log of the current update operation to the log buffer. If neither difference reaches 200 ms, the participant writes the log of the current update operation to the log buffer.

[0069] After the log of the current update operation is successfully written to the log buffer, the participant encapsulates the timestamp for writing the log of the current update operation to the log buffer in a write lock pre-release request to send to the coordinator.

[0070] After receiving the write lock pre-release requests sent by all participants, the coordinator uses the latest timestamp among all the write lock pre-release requests that write the log of the update operation to the log buffer as the commit timestamp of the current transaction. The coordinator adds the commit timestamp of the current transaction to the write lock pre-release response to be sent to each participant.

[0071] After receiving the write lock pre-release response, the participant writes the log commit time of the current transaction in the write lock pre-release response to the transaction information registration table, and unlocks the write lock on the target row.

[0072] After successfully synchronizing the log of the update operation of the current transaction to the three backup log files in the log buffer, the participant queries the state of each preceding transaction in the entry of the current transaction in the transaction information registration table, and sends a phase 1 prepare response message indicating successful prepare to the coordinator after all preceding transactions have entered the committed state, or sends a phase 1 prepare response message indicating unsuccessful prepare to the coordinator after any preceding transaction has entered the aborted state.

[0073] In the commit / abort phase, if the messages received by the coordinator from all participants are phase 1 prepare response messages indicating successful prepare, the coordinator sends a commit message to each participant. If any participant returns a prepare failure, the coordinator sends an abort message to all participants. The participants commit or abort the current transaction in phase 2 based on the commit or abort message received from the coordinator, write the state of the current transaction as committed or aborted in the transaction information record, and similarly write the state of the current transaction as committed or aborted in the entry of the successor transaction of the current transaction.

[0074] Participants maintain the state of the current transaction and the identifier of the current transaction's predecessor transaction in a transaction information registration table in a log file, which ensures data accuracy in the recovery process after a restart due to an outage or primary-secondary switch.

[0075] In this application example, suppose that transactions T1, T2, and T3 of a participant use the same row Row1 in the database as the target of the update operation. The execution sequence of T1, T2, and T3 under maximum possible concurrency is shown in Figure 6. It can be seen that the concurrency performance has been significantly improved compared to Figure 2.

[0076] Corresponding to the implementation of the above procedure, the implementation of this specification further provides a device applied to a participant to update a database by using two-phase commit distributed transactions, and a device applied to a coordinator to update a database by using two-phase commit distributed transactions. Each of the two devices can be implemented by software or a combination of software and hardware. An example in which the device is implemented by software is used. As a logical device, the device is formed by a central processing unit (CPU) of a device in which the device is installed reading corresponding computer program instructions and executing the instructions in a storage device. From a hardware perspective, in addition to the CPU, storage device, and memory shown in FIG. 7, a device in which the device for updating a database by using two-phase commit distributed transactions is installed typically further includes at least one other hardware such as a chip for wireless signal transmission and reception, or a board used to implement network communication functions.

[0077] 8 illustrates an apparatus for updating a database by using a two-phase commit distributed transaction provided in an implementation form of the present specification. The apparatus is applied to a participant and includes an update operation execution unit, a previous transaction discovery unit, a write lock release request unit, a write lock pre-release unit, a first prepare response sending unit, and a commit-abort state unit. The update operation execution unit is configured to add a write lock to the target database record according to an instruction for updating the target database record in the current transaction, and then execute the update operation according to the instruction. The previous transaction discovery unit is configured to record a previous transaction of the current transaction in the transaction information record using another transaction in the transaction information record whose state is to release the write lock beforehand and whose update target involves the target database record as the previous transaction of the current transaction. The write lock release request unit is configured to write a log of the update operation of the current transaction to a log buffer after receiving a phase 1 prepare request message sent by the coordinator, and to send a write lock pre-release request to the coordinator after the write is successful. The write lock pre-release unit is configured to release the write lock after receiving a write lock pre-release response returned by the coordinator, and set a state of the current transaction in the transaction information record to pre-release the write lock. The first prepare response sending unit is configured to send a prepare successful phase 1 prepare response message to the coordinator after all preceding transactions of the current transaction enter a committed state, or send a prepare unsuccessful phase 1 prepare response message to the coordinator after any preceding transaction of the current transaction enters an aborted state, after successfully retaining logs of the update operations of the current transaction in the log buffer.The commit-abort state unit is configured to set the current transaction in the transaction information record to a committed state or an aborted state based on the execution result of the current transaction in phase 2.

[0078] Optionally, the apparatus further includes a second prepare response sending unit configured to send a prepare successful phase 1 prepare response message to the coordinator after successfully retaining a log of the update operation of the current transaction in the log buffer when the current transaction has no preceding transaction.

[0079] Optionally, the write lock pre-release response carries a commit timestamp generated by the coordinator. The apparatus further includes a commit timestamp writing unit configured to record a commit timestamp of the current transaction in the transaction information record. Performing the update operation according to the instruction by the update operation execution unit includes performing the update operation according to the instruction after the preceding transaction enters a committed state or an aborted state when a difference between the timestamp of the current update operation and the commit timestamp of a preceding transaction of the current transaction reaches or exceeds a first threshold.

[0080] Optionally, the write lock pre-release response carries a commit timestamp generated by the coordinator. The apparatus further includes a commit timestamp writing unit configured to record a commit timestamp of the current transaction in the transaction information record. Writing a log of the update operation of the current transaction into the log buffer by the write lock pre-release unit includes writing the log of the update operation of the current transaction into the log buffer after the preceding transaction enters a committed state or an aborted state when a difference between a timestamp for writing the update operation of the current transaction into the log buffer and a commit timestamp of a preceding transaction of the current transaction reaches or exceeds a second threshold.

[0081] Optionally, the write lock pre-release request carries a timestamp at which the coordinator writes a log of the update operations of the current transaction to a log buffer to generate a commit timestamp for the current transaction.

[0082] Optionally, recording the predecessor transactions of the current transaction in the transaction information record by the predecessor transaction discovery unit includes writing each predecessor transaction of the current transaction and a status of the predecessor transaction in an entry of the current transaction in the transaction information record, and recording the current transaction in the entry of each predecessor transaction of the current transaction as a successor transaction of the predecessor transaction. The commit-abort state unit is specifically configured to update the state in the entry of the current transaction in the transaction information record to a committed state or an aborted state, and update the state of the current transaction in the entry of the successor transaction of the current transaction to a committed state or an aborted state based on an execution result of the current transaction in the commit / abort phase.

[0083] Optionally, the apparatus further comprises a previous transaction persistence unit configured to persist a state of the current transaction and a previous transaction of the current transaction in a transaction information record.

[0084] 9 illustrates an apparatus for updating a database by using a two-phase commit distributed transaction provided in an implementation form of the present specification. The apparatus is applied to a coordinator and includes a prepare request sending unit and a write lock release response unit. The prepare request sending unit is configured to send a phase 1 prepare request message to each participant to terminate a current transaction being used to update a target database record. The write lock release response unit is configured to return a write lock pre-release response to each participant to instruct each participant to unlock the target database record of the participant after receiving the write lock pre-release requests sent by all participants, and the write lock pre-release request is sent by a participant after the participant successfully writes the log of the update operation of the current transaction to a log buffer.

[0085] In one example, the apparatus further includes a commit timestamp generation unit configured to generate a commit timestamp of the current transaction after receiving the write lock pre-release requests sent by all participants, where the write lock pre-release response carries the commit timestamp of the current transaction.

[0086] In the above example, the write lock pre-release request carries a timestamp at which the participant sending the pre-release request writes the log of the update operation of the current transaction to the log buffer. Generating the commit timestamp of the current transaction by the commit timestamp generation unit includes using the latest timestamp among the timestamps at which the log is written to the log buffer in the pre-release requests sent by all participants as the commit timestamp of the current transaction.

[0087] An implementation of the present specification provides a computer device. The computer device includes a memory and a processor. The memory stores a computer program that can be executed by the processor. When the processor executes the stored computer program, steps of a method applied to a participant for updating a database by using a two-phase commit distributed transaction in the implementation of the present specification are performed. For a detailed description of each step of the method applied to a participant for updating a database by using a two-phase commit distributed transaction, reference may be made to the above content. For simplicity, details are omitted in this specification.

[0088] An implementation of the present specification provides a computer device. The computer device includes a memory and a processor. The memory stores a computer program that can be executed by the processor. When the processor executes the stored computer program, steps of a method applied to a coordinator for updating a database by using two-phase commit distributed transactions in the implementation of the present specification are executed. For a detailed description of each step of the method applied to a coordinator for updating a database by using two-phase commit distributed transactions, reference may be made to the above content. For simplicity, details are omitted in this specification.

[0089] An implementation of the present specification provides a computer-readable storage medium. The storage medium stores a computer program. When the computer program is executed by a processor, steps of a method applied to a participant for updating a database by using a two-phase commit distributed transaction in the implementation of the present specification are performed. For a detailed description of each step of the method applied to a participant for updating a database by using a two-phase commit distributed transaction, reference may be made to the above content. For simplicity, details are omitted in this specification.

[0090] An implementation of the present specification provides a computer-readable storage medium. The storage medium stores a computer program. When the computer program is executed by a processor, steps of a method applied to a coordinator for updating a database by using a two-phase commit distributed transaction in the implementation of the present specification are executed. For a detailed description of each step of the method applied to a coordinator for updating a database by using a two-phase commit distributed transaction, reference may be made to the above content. For simplicity, details are omitted in this specification.

[0091] The above merely shows the preferred implementation of the present specification, and is not intended to limit other embodiments from being claimed for protection. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present specification shall fall within the scope of protection.

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

[0093] The memory may include at least one of a non-permanent memory in a computer-readable medium, a random access memory (RAM), or a non-volatile memory such as a read-only memory (ROM) or a flash memory (flash RAM). The memory is an example of a computer-readable medium.

[0094] Computer-readable media include permanent and non-permanent media and removable and non-removable media, and information can be stored using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change random access memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), another type 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 disk (DVD) or other optical storage, magnetic cassette, disk storage, tape disk storage, or other magnetic storage device or any other non-transmission medium, which can be configured to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carriers.

[0095] It is further worth noting that the terms "comprise," "comprises," or any other variations thereof, are intended to cover a non-exclusive inclusion, whereby a process, method, article, or device that includes a series of elements not only includes those elements, but also includes other elements not expressly listed or that are inherent in such process, method, article, or device. In the absence of further constraints, an element defined by the phrase "comprises" does not exclude the presence of other equivalent elements in a process, method, article, or device that includes that element.

[0096] Those skilled in the art will appreciate that implementations of the present specification may provide a method, a system, or a computer program product. Thus, implementations of the present specification may take the form of an entirely hardware implementation, an entirely software implementation, or an implementation combining software and hardware. In addition, implementations of the present specification may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

Claims

1. 1. A method for updating a database by using a two-phase commit distributed transaction, comprising: adding a write lock to a target database record, and then performing an update operation according to instructions for updating said target database record within the current transaction; recording the preceding transaction of the current transaction in the transaction information record using another transaction in the transaction information record as the preceding transaction of the current transaction, where the state of the other transaction is to previously release the write lock and an update target of the other transaction involves the target database record; After receiving a phase 1 prepare request message sent by a coordinator device, writing a log of the update operation of the current transaction to a log buffer, and after the writing is successful, sending a write lock pre-release request to the coordinator device; Releasing the write lock after receiving a write lock pre-release response returned by the coordinator device, and setting a state of the current transaction in the transaction information record to pre-release the write lock; After successfully storing the log of the update operation of the current transaction in the log buffer, sending a phase 1 prepare response message indicating a prepare success to the coordinator device after all preceding transactions of the current transaction have entered a committed state, or sending a phase 1 prepare response message indicating a prepare failure to the coordinator device after any preceding transaction of the current transaction has entered an aborted state; setting the current transaction in the transaction information record to a committed state or an aborted state based on the execution result of the current transaction in phase 2; A method for performing an operation including:

2. 2. The method of claim 1, further comprising: when the current transaction has no preceding transactions, after successfully retaining the log of the update operations of the current transaction in the log buffer, sending the phase 1 prepare response message indicating successful prepare to the coordinator device.

3. the write lock pre-release response carries a commit timestamp generated by the coordinator device; the method further comprising recording a commit timestamp of the current transaction in the transaction information record; 2. The method of claim 1, wherein the step of performing the update operation according to the instruction comprises: performing the update operation according to the instruction after the preceding transaction enters the committed state or the aborted state when a difference between a timestamp of a current update operation and a commit timestamp of the preceding transaction of the current transaction reaches or exceeds a first threshold.

4. the write lock pre-release response carries a commit timestamp generated by the coordinator device; the method further comprising recording a commit timestamp of the current transaction in the transaction information record; 2. The method of claim 1, wherein the step of writing the log of the update operations of the current transaction into the log buffer comprises writing the log of the update operations of the current transaction into the log buffer after the preceding transaction enters the committed state or the aborted state when a difference between a timestamp at which the update operations of the current transaction are written into the log buffer and a commit timestamp of the preceding transaction of the current transaction reaches or exceeds a second threshold.

5. 2. The method of claim 1, wherein the write lock pre-release request carries a timestamp at which the coordinator device writes the log of the update operations of the current transaction to the log buffer to generate a commit timestamp for the current transaction.

6. the step of recording the preceding transaction of the current transaction in the transaction information record includes the steps of writing each preceding transaction of the current transaction and a status of the preceding transaction in an entry for the current transaction in the transaction information record, and recording the current transaction as a successor transaction of the preceding transaction in the entry for each preceding transaction of the current transaction; The step of setting the current transaction in the transaction information record to the committed state or the aborted state based on the execution result of the current transaction in phase 2 includes the steps of: updating the state in the entry of the current transaction in the transaction information record to the committed state or the aborted state based on the execution result of the current transaction in the commit / abort phase; and updating the state of the current transaction in the entry of a subsequent transaction of the current transaction to the committed state or the aborted state.

2. The method of claim 1, comprising:

7. The method of claim 1 , further comprising the step of maintaining a state of the current transaction and the predecessor transaction of the current transaction in the transaction information record.

8. 1. A method for updating a database by using a two-phase commit distributed transaction, comprising: sending a phase 1 prepare request message to each participant device to terminate the current transaction being used to update the target database record; after receiving the write lock pre-release requests sent by all the participant devices, returning a write lock pre-release response to each participant device to instruct each participant device to unlock the target database record of the participant device; wherein the write lock pre-release request is sent by the participant device after the participant device successfully writes a log of an update operation of the current transaction to a log buffer.

9. generating a commit timestamp for the current transaction after receiving the write lock pre-release requests sent by all of the participant devices; The method of claim 8 , wherein the write lock pre-release response carries the commit timestamp of the current transaction.

10. the write lock pre-release request carries a timestamp at which the participant device sending the write lock pre-release request writes the log of the update operation of the current transaction to the log buffer; 10. The method of claim 9, wherein generating the commit timestamp for the current transaction comprises using the latest timestamp among the timestamps at which the log is written to the log buffer in the write lock pre-release requests sent by all of the participant devices as the commit timestamp for the current transaction.

11. 1. An apparatus for updating a database by using a two-phase commit distributed transaction, the apparatus being applied to a participant, comprising: an update operation execution unit configured to add a write lock to a target database record and then execute an update operation according to an instruction for updating said target database record within a current transaction; a previous transaction discovery unit configured to record the previous transaction of the current transaction in the transaction information record using another transaction in the transaction information record as the previous transaction of the current transaction, wherein a state of the other transaction is to previously release the write lock and an update target of the other transaction involves the target database record; a write unlock request unit configured to write a log of the update operation of the current transaction to a log buffer after receiving a phase 1 prepare request message sent by a coordinator, and to send a write lock pre-release request to the coordinator after the write is successful; a write lock pre-release unit configured to release the write lock after receiving a write lock pre-release response returned by the coordinator, and set a state of the current transaction in the transaction information record to pre-release the write lock; a first prepare response sending unit configured to, after successfully retaining the log of the update operation of the current transaction in the log buffer, send a phase 1 prepare response message of prepare success to the coordinator after all preceding transactions of the current transaction have entered a committed state, or to send a phase 1 prepare response message of prepare failure to the coordinator after any preceding transaction of the current transaction has entered an aborted state; a commit-abort state unit configured to set the current transaction in the transaction information record to a committed state or an aborted state based on an execution result of the current transaction in phase 2; 1. An apparatus comprising:

12. 12. The apparatus of claim 11, further comprising: a second prepare response sending unit configured to send the phase 1 prepare response message of prepare success to the coordinator after successfully retaining the log of the update operations of the current transaction in the log buffer when the current transaction has no preceding transactions.

13. the write lock pre-release response carries a commit timestamp generated by the coordinator; the apparatus further comprises a commit timestamp writing unit configured to record a commit timestamp of the current transaction in the transaction information record; 12. The apparatus of claim 11, wherein the executing, by the update operation execution unit, the update operation in accordance with the instruction comprises executing the update operation in accordance with the instruction after the preceding transaction enters the committed state or the aborted state when a difference between a timestamp of a current update operation and a commit timestamp of the preceding transaction of the current transaction reaches or exceeds a first threshold.

14. the write lock pre-release response carries a commit timestamp generated by the coordinator; the apparatus further comprises a commit timestamp writing unit configured to record a commit timestamp of the current transaction in the transaction information record; 12. The apparatus of claim 11, wherein writing the log of the update operation of the current transaction into the log buffer by the write lock pre-release unit comprises writing the log of the update operation of the current transaction into the log buffer after the preceding transaction enters the committed state or the aborted state when a difference between a timestamp at which the update operation of the current transaction is written into the log buffer and a commit timestamp of the preceding transaction of the current transaction reaches or exceeds a second threshold.

15. 12. The apparatus of claim 11, wherein the write lock pre-release request carries the timestamp that the coordinator uses to write the log of the update operations of the current transaction to the log buffer to generate a commit timestamp for the current transaction.

16. The recording by the previous transaction discovery unit of the previous transaction of the current transaction in the transaction information record includes writing each previous transaction of the current transaction and a status of the previous transaction in an entry of the current transaction in the transaction information record; and recording the current transaction as a successor transaction of the previous transaction in an entry of each previous transaction of the current transaction. Including, 12. The apparatus of claim 11, wherein the commit-abort state unit is specifically configured to update a state in the entry of the current transaction in the transaction information record to the committed state or the abort state based on the execution result of the current transaction in a commit / abort phase, and to update a state of the current transaction in an entry of a successor transaction of the current transaction to the committed state or the abort state.

17. The apparatus of claim 11 , further comprising a previous transaction persistence unit configured to persist a state of the previous transaction of the current transaction and the current transaction in the transaction information record.

18. 1. An apparatus for updating a database by using a two-phase commit distributed transaction, the apparatus being applied to a coordinator, a prepare request sending unit configured to send a phase 1 prepare request message to each participant to terminate a current transaction being used to update the target database record; a write lock release response unit configured to, after receiving the write lock pre-release requests sent by all participants, return a write lock pre-release response to each participant to instruct each participant to unlock the target database record of said participant; wherein the write lock pre-release request is sent by the participant after the participant has successfully written a log of an update operation of the current transaction to a log buffer.

19. a commit timestamp generating unit configured to generate a commit timestamp of the current transaction after receiving the write lock pre-release requests sent by all the participants; 20. The apparatus of claim 18, wherein the write lock pre-release response carries the commit timestamp of the current transaction.

20. the write lock pre-release request carries a timestamp at which the participant sending the write lock pre-release request writes the log of the update operation of the current transaction to the log buffer; 20. The apparatus of claim 19, wherein generating the commit timestamp of the current transaction by the commit timestamp generation unit includes using the latest timestamp among the timestamps at which the log is written to the log buffer in the write lock pre-release requests sent by all of the participants as the commit timestamp of the current transaction.

21. A computer device comprising a memory and a processor, wherein the memory stores a computer program that can be executed by the processor, and wherein the steps of any one of claims 1 to 7 are performed when the processor executes the computer program.

22. 11. A computer device comprising a memory and a processor, wherein the memory stores a computer program that can be executed by the processor, and wherein the steps of any one of claims 8 to 10 are performed when the processor executes the computer program.

23. A computer-readable storage medium storing a computer program, the computer program causing the steps of any one of claims 1 to 7 to be performed when executed by a processor.

24. A computer-readable storage medium storing a computer program, the computer program causing the steps of any one of claims 8 to 10 to be performed when executed by a processor.

Images