Distributed transaction processing method, system and device, storage medium and program product

Abstract

The invention relates to the technical field of distributed computing, and particularly provides a distributed transaction processing method, system and device, a storage medium and a program product. The method comprises the following steps: a transaction manager sends a registration and opening request of a global transaction to a transaction coordinator; the transaction coordinator registers and opens a global transaction, and allocates a global lock for the global transaction; the transaction manager sends a calling request to each resource manager according to a preset execution sequence; each resource manager starts a branch transaction indicated by the call request and determines an execution state of a preparation stage; respectively sending an execution state to a transaction manager and a transaction coordinator; the transaction manager determines an execution decision of an execution stage based on the execution states of the plurality of branch transactions; sending a decision confirmation request to the transaction coordinator based on the execution decision; releasing the local locks of the plurality of branch transactions under the condition that the execution decision is submission; the transaction coordinator determines a decision confirmation result based on the execution states of the plurality of branch transactions; under the condition that the decision confirmation result is submission, submission instructions are sent to a plurality of resource managers, and the global lock is released; and each resource manager asynchronously submits each branch transaction and asynchronously deletes the rollback log. The resource locking time can be remarkably shortened, and the concurrent processing capacity of the distributed transaction processing system is improved.

Description

Technical Field

[0001] This disclosure relates to the field of distributed computing technology, and in particular to a distributed transaction processing method, system, device, storage medium, and program product. Background Technology

[0002] Distributed transaction processing is a key technology for ensuring consistency in data operations across multiple independent systems or databases, and it is widely used in microservices and cloud-native architectures. Currently, distributed transaction processing solutions are typically based on the two-phase commit (2PC) mechanism of the eXtended Architecture (XA) protocol. This mechanism can coordinate multiple resources through a transaction coordinator, locking data during the preparation phase and completing the operation uniformly during the commit phase.

[0003] With the rapid development of business, the requirements for concurrency and performance are becoming increasingly stringent in some business scenarios. However, the XA protocol has significant shortcomings in high-concurrency scenarios: transactions hold database locks for an extended period after the preparation phase, only releasing them at the end of the second phase. This can easily lead to data being locked for a long time, resulting in decreased concurrency capabilities and slower response times in the distributed system, thus impacting business processing efficiency. Summary of the Invention

[0004] This disclosure is made in view of the above-mentioned problems. This disclosure provides a distributed transaction processing method, system, device, storage medium, and program product.

[0005] According to one aspect of this disclosure, a distributed transaction processing method is provided, applied to a distributed transaction processing system, the distributed transaction processing system including a transaction coordinator, a transaction manager, and multiple resource managers; the method includes: The transaction manager sends a registration and start request for the global transaction of the business to be executed to the transaction coordinator; The transaction coordinator responds to the registration and start request by registering and starting the global transaction and allocating a global lock for the global transaction. The transaction manager sends call requests to each of the resource managers according to the preset execution order of the multiple branch transactions corresponding to the global transaction; Each of the resource managers responds to the call request, starts the branch transaction indicated by the call request, and determines the execution status of each branch transaction in the preparation phase; the execution status is sent to the transaction manager and the transaction coordinator respectively; wherein, the preparation phase includes: acquiring a local lock, constructing a rollback log, and committing the rollback log, and the execution status is used to indicate whether the preparation phase was executed successfully; The transaction manager determines the execution resolution of the multiple branch transactions in the execution phase based on the execution status of the multiple branch transactions in the preparation phase; based on the execution resolution, it sends a resolution confirmation request for the global transaction to the transaction coordinator; and if the execution resolution is a commit, it releases the local locks of the multiple branch transactions. In response to the resolution confirmation request, the transaction coordinator determines the resolution confirmation result of the global transaction based on the execution status of the multiple branch transactions in the preparation phase; if the resolution confirmation result is a commit, the coordinator sends a commit instruction of the multiple branch transactions in the execution phase to the multiple resource managers and releases the global lock. In response to the commit instruction, each of the resource managers asynchronously commits each of the branch transactions according to a preset execution order, and asynchronously deletes the rollback logs of each of the branch transactions.

[0006] According to another aspect of this disclosure, a distributed transaction processing system is provided, including a transaction coordinator, a transaction manager, and multiple resource managers; The transaction manager is configured to send a registration and start request for a global transaction for the business to be executed to the transaction coordinator; The transaction coordinator is configured to register and start the global transaction in response to the registration and start request, and to allocate a global lock for the global transaction; The transaction manager is configured to send call requests to each of the resource managers according to the preset execution order of the multiple branch transactions corresponding to the global transaction; Each of the resource managers is configured to respond to the call request, start the branch transaction indicated by the call request, and determine the execution status of each branch transaction in the preparation phase; and send the execution status to the transaction manager and the transaction coordinator respectively; wherein, the preparation phase includes: acquiring a local lock, constructing a rollback log, and committing the rollback log, and the execution status is used to indicate whether the preparation phase was executed successfully; The transaction manager is configured to determine the execution resolution of the multiple branch transactions in the execution phase based on the execution status of the multiple branch transactions in the preparation phase; send a resolution confirmation request for the global transaction to the transaction coordinator based on the execution resolution; and release the local locks of the multiple branch transactions if the execution resolution is a commit. The transaction coordinator is configured to, in response to the resolution confirmation request, determine the resolution confirmation result of the global transaction based on the execution status of the multiple branch transactions in the preparation phase; if the resolution confirmation result is a commit, send a commit instruction of the multiple branch transactions in the execution phase to the multiple resource managers, and release the global lock; Each of the resource managers is configured to, in response to the commit instruction, asynchronously commit each of the branch transactions in a preset execution order, and asynchronously delete the rollback logs of each of the branch transactions.

[0007] In another aspect of exemplary embodiments of this disclosure, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory, the processor executing the computer program to implement the methods described in exemplary embodiments of this disclosure.

[0008] In another aspect of exemplary embodiments of the present disclosure, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the methods described in exemplary embodiments of the present disclosure.

[0009] In another aspect of the exemplary embodiments of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the methods described in the exemplary embodiments of this disclosure.

[0010] As will be described in detail below, the distributed transaction processing method according to embodiments of this disclosure involves a transaction manager sending a registration and start request for a global transaction of a business to be executed to a transaction coordinator; the transaction coordinator, in response to the registration and start request, registers and starts the global transaction and allocates a global lock for the global transaction; the transaction manager sends a call request to each resource manager according to the preset execution order of multiple branch transactions corresponding to the global transaction; each resource manager, in response to the call request, starts the branch transaction indicated by the call request and determines the execution status of each branch transaction in the preparation phase; and sends the execution status to the transaction manager and the transaction coordinator respectively; wherein, the preparation phase includes: acquiring a local lock, constructing a rollback log, and committing the rollback log, and the execution status is used to indicate whether the preparation phase was successfully executed; the transaction manager determines multiple... The process involves the following steps: First, the branch transaction makes an execution decision during the execution phase. Based on this decision, a global transaction resolution confirmation request is sent to the transaction coordinator. If the execution decision is not a commit, the local locks of multiple branch transactions are released. The transaction coordinator responds to the resolution confirmation request by determining the global transaction resolution confirmation result based on the execution status of multiple branch transactions during the preparation phase. If the resolution confirmation result is a commit, multiple branch transaction commit instructions are sent to multiple resource managers during the execution phase, and the global lock is released. Each resource manager responds to the commit instructions by asynchronously committing each branch transaction according to a preset execution order and asynchronously deleting the rollback logs of each branch transaction. This process significantly reduces resource locking time while maintaining the atomicity, consistency, isolation, and durability (ACID properties) of transactions, improving the concurrent processing capability and overall performance of the distributed transaction processing system, and ensuring efficient business operation.

[0011] It should be understood that both the foregoing general description and the following detailed description are exemplary and intended to provide further illustration of the claimed technology. Attached Figure Description

[0012] The above and other objects, features, and advantages of this disclosure will become more apparent from the more detailed description of the embodiments thereof in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this disclosure and form part of the specification. They are used together with the embodiments of this disclosure to explain the disclosure and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0013] Figure 1 A flowchart illustrating the XA transaction processing procedure provided in related technologies is shown; Figure 2 A schematic diagram of the architecture of a distributed transaction processing system provided in an exemplary embodiment of this disclosure is shown. Figure 3 A flowchart illustrating a distributed transaction processing method provided in an exemplary embodiment of this disclosure is shown. Figure 4 A schematic diagram of the resource locking process in distributed transaction processing provided by related technologies is shown; Figure 5 A schematic diagram illustrating the resource locking process for distributed transaction processing provided in an exemplary embodiment of this disclosure is shown. Figure 6 A schematic diagram of a computer program product provided with an exemplary embodiment of the present disclosure is shown; Figure 7 A hardware block diagram of an electronic device provided in an exemplary embodiment of the present disclosure is shown. Detailed Implementation

[0014] To make the objectives, technical solutions, and advantages of this disclosure more apparent, exemplary embodiments according to this disclosure will now be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this disclosure, and not all embodiments of this disclosure. It should be understood that this disclosure is not limited to the exemplary embodiments described herein.

[0015] It should be understood that the steps described in the method embodiments of this disclosure may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this disclosure is not limited in this respect.

[0016] The term "comprising" and its variations as used herein are open-ended, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the description below. It should be noted that the concepts of "first", "second", etc., used in this disclosure are only used to distinguish different devices, modules, or units, and are not intended to limit the order of functions performed by these devices, modules, or units or their interdependencies.

[0017] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0018] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0019] Distributed transaction processing is a key technology in distributed computing environments, designed to ensure that data operations across multiple independent resources (such as databases, message queues, and file systems) maintain atomicity, consistency, isolation, and durability (ACID). With the increasing prevalence of microservice architectures and cloud-native applications, business systems often need to coordinate multiple services or databases to complete a single business operation, which places higher demands on the consistency of distributed transactions.

[0020] Figure 1 A flowchart illustrating the XA transaction processing procedure provided in related technologies is shown, such as... Figure 1As shown, a global transaction is started within the same thread, and resource operations are then executed separately through resource registration. The specific process is as follows: 1. Start a global transaction: The application (also known as the application server, Application, AP) starts a global transaction through its internal Transaction Manager (TM). The TM generates a unique global transaction identifier (XID); 2. Register the first branch transaction resource: The TM notifies the first Resource Manager (RM) (i.e., RM1) to start a first branch transaction belonging to this global transaction (register resource 1); 3. Execute the data operations of the first branch transaction; 4. Register the second branch transaction resource: The TM notifies the second Resource Manager (i.e., RM2) to start a second branch transaction belonging to this global transaction (register resource 2); 5. Execute the data operations of the second branch transaction; 6. Commit the transaction. After all branch transaction data operations have been completed, the TM, as the coordinator, issues a "prepare" instruction to all participants; 7. Execute the preparation for the first branch transaction; 8. Execute the preparation for the second branch transaction; 9. Commit / rollback the first branch transaction; 10. Commit / rollback the second branch transaction.

[0021] Upon receiving the "Ready" instruction, each Resource Manager (RM) checks its own status. If everything is ready (data modification successful, logs written), it replies to the Transaction Manager (TM) with "Agree to commit" and persists the local transaction to the "Ready" state. At this point, the local lock remains in place. If any RM fails or cannot complete preparation, it replies with "Rollback recommended." This completes the first phase (the preparation phase).

[0022] In the second phase (commit / rollback phase), the TM collects responses from all RMs. If all RMs reply "agree to commit," the TM makes a final decision to commit globally. If any RM replies "suggest rollback" or a timeout occurs, the TM makes a decision to rollback globally. Figure 1 As shown, "6. Commit Transaction" indicates that the Transaction Manager (TM) has made a commit decision and notified the two Resource Managers (RMs). Upon receiving the TM's commit command, RM1 and RM2 formally commit their respective local transactions, making all data modifications permanent. If it is a rollback decision, the RMs will revert all data modifications within their current transaction based on previously written logs. Only after the second phase (commit or rollback) is fully completed will each RM release the local database locks it has held since the preparation phase.

[0023] from Figure 1As can be seen, the basic process of XA transaction processing can include: first, starting a global transaction; then, registering and executing branch transactions on each participating resource; in the first stage (preparation stage), each resource performs operations and locks relevant data; in the second stage (commit / rollback stage), all branch transactions are committed or rolled back in a unified manner based on the global coordination results; and finally, the resource locks are released.

[0024] The XA protocol, implemented in databases, offers lower costs for programs using distributed transactions. However, the isolation of the XA model is guaranteed by the local database, with locks stored in each local database. Once the prepare operation is performed, the XA transaction cannot be re-entered, nor can it share locks with other XA transactions. This characteristic can lead to data being locked for extended periods in high-concurrency and long-transaction scenarios, resulting in inefficient business operations.

[0025] Therefore, in order to solve the above problems, this disclosure provides a distributed transaction processing method that can significantly reduce resource locking time and improve the concurrent processing capability and overall performance of the distributed transaction processing system while maintaining the atomicity, consistency, isolation and durability (ACID properties) of transactions.

[0026] The distributed transaction processing method provided in this disclosure is applied to a distributed transaction processing system. Figure 2 This disclosure illustrates a schematic diagram of the architecture of a distributed transaction processing system provided in an exemplary embodiment, such as... Figure 2 As shown, the distributed transaction processing system 200 includes a transaction coordinator (TC) 201, a transaction manager 202, and multiple resource managers 203.

[0027] For example, the transaction coordinator 201, transaction manager 202, and multiple resource managers 203 can be independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers that provide basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms. This exemplary embodiment does not limit these features.

[0028] like Figure 2 As shown, based on the two-phase commit (2PC) mechanism of the XA protocol, this embodiment of the disclosure uses a transaction coordinator 201 to coordinate the transaction manager 202 and multiple resource managers 203 to jointly complete the global transaction of the business to be executed.

[0029] The transaction coordinator 201 ensures the consistency of global transactions, maintains the execution state of global and branch transactions, and drives the commit or rollback of global transactions. The transaction coordinator 201 can communicate with the resource managers of each branch transaction to ensure that all branch transactions execute according to the requirements of the global transaction. Here, a global transaction refers to a transaction spanning multiple services or resources, while a branch transaction is a local transaction on each service or resource involved in the global transaction.

[0030] Transaction Manager 202 is responsible for defining the scope of multiple branch transactions corresponding to a global transaction, initiating a global transaction, monitoring the execution progress of each branch transaction, and handling the commit or rollback confirmation requests for the global transaction.

[0031] Resource Manager 203 may include, but is not limited to, databases, file systems, etc., and provides ways to access resources. Resource Manager 203 manages resources for branch transaction processing, communicates with Transaction Coordinator 201 to register branch transactions and report the execution status of branch transactions, and drives branch transactions to commit or rollback.

[0032] Figure 3 A flowchart illustrating a distributed transaction processing method provided in an exemplary embodiment of this disclosure is shown. Figure 3 As shown, the distributed transaction processing method includes: S301, The transaction manager sends a request to the transaction coordinator to register and start the global transaction for the business to be executed; S302, the transaction coordinator responds to the registration and start request, registers and starts a global transaction, and allocates a global lock for the global transaction; S303, the transaction manager sends call requests to each resource manager according to the preset execution order of multiple branch transactions corresponding to the global transaction; S304, each resource manager responds to the call request, starts the branch transaction indicated by the call request, and determines the execution status of each branch transaction in the preparation phase; and sends the execution status to the transaction manager and the transaction coordinator respectively; wherein, the preparation phase includes: acquiring local locks, constructing rollback logs, and committing rollback logs, and the execution status is used to indicate whether the preparation phase was executed successfully; S305, the transaction manager determines the execution decision of multiple branch transactions in the execution phase based on the execution status of multiple branch transactions in the preparation phase; based on the execution decision, it sends a global transaction decision confirmation request to the transaction coordinator; and if the execution decision is to commit, it releases the local locks of multiple branch transactions. S306, In response to the resolution confirmation request, the transaction coordinator determines the resolution confirmation result of the global transaction based on the execution status of multiple branch transactions in the preparation phase; if the resolution confirmation result is a commit, it sends commit instructions for multiple branch transactions in the execution phase to multiple resource managers and releases the global lock. In S307, each resource manager responds to the commit instruction, asynchronously commits each branch transaction according to the preset execution order, and asynchronously deletes the rollback log of each branch transaction.

[0033] Specifically, the aforementioned pending business operations refer to business operations that need to be executed as a complete process across multiple services or resources. These pending business operations must satisfy the ACID properties of transactions, especially atomicity and consistency. In other words, for the global transaction corresponding to the pending business operations, all branch transactions must either all succeed or all fail, and intermediate states are not visible to the outside world.

[0034] The aforementioned pending service can be initiated by the user on the terminal. Here, the terminal may include one or more of the following: mobile phone, tablet computer, wearable device, in-vehicle device, laptop computer, ultra-mobile personal computer (UMPC), netbook, PDA (personal digital assistant), and wearable device based on augmented reality (AR) and / or virtual reality (VR) technology. The exemplary embodiments disclosed herein do not impose specific limitations on this.

[0035] For example, in an e-commerce system, when a user submits an order and completes payment, the aforementioned pending business can be the order payment business. After receiving the order payment business, the transaction manager sends a global transaction registration and start request for the pending business to the transaction coordinator.

[0036] In response to registration and start requests, the transaction coordinator can register and start a global transaction for the business to be executed, and allocate a global lock for the global transaction. Here, the global lock can be used to lock the relevant data involved in the global transaction (for example, locking the inventory records and payment account involved in the order payment business), ensuring that the relevant data is not modified by other transactions during the execution of the global transaction.

[0037] A global transaction has multiple corresponding branch transactions to complete the pending business logic. These branch transactions have a preset execution order, with the start of a later branch transaction depending on the completion of an earlier branch transaction. Based on this, the transaction manager sends call requests to each resource manager according to the preset execution order of the multiple branch transactions corresponding to the global transaction.

[0038] For example, the multiple branch transactions corresponding to an order payment transaction may include order services, inventory services, and payment services ordered according to a preset execution order. First, the transaction manager sends a call request to the resource manager corresponding to the order service. In response to this call request, the resource manager starts the order service and determines its execution status in the preparation phase (i.e., the first phase); it then sends this execution status to the transaction manager. If the order service's execution status in the preparation phase is successful, the transaction manager sends a call request to the resource manager corresponding to the inventory service, so that the resource manager can determine the execution status of the inventory service in the preparation phase. This process continues until multiple resource managers determine the execution status of all branch transactions in the preparation phase.

[0039] The preparation phase here may include: acquiring a local lock, constructing an undo log, and committing the undo log. Specifically, the resource manager acquires a local lock on the data to be modified within the corresponding branch of the transaction in the local database. This locks the data, ensuring that other transactions cannot modify it during the preparation phase, providing a stable data view for the subsequent construction of the undo log. Under the protection of the local lock, the undo log is constructed, recording the state of the data before and after the change, forming the basis for the rollback. Finally, the undo log is committed to the local database, releasing local resources.

[0040] After determining the execution status of each branch transaction during the preparation phase, the resource manager can send that execution status to the transaction coordinator, so that the transaction coordinator can record the execution status of that branch transaction for its registered users. Here, the execution status indicates whether the preparation phase was successful. A successful execution status indicates that the preparation phase of the branch transaction is complete; a failed execution status indicates that the preparation phase of the branch transaction is not complete.

[0041] For example, the transaction coordinator can register a branch transaction if the branch transaction's execution status during the preparation phase is successful.

[0042] After receiving the execution status of multiple branch transactions during the preparation phase from multiple resource managers, the transaction manager can determine the execution decision for the multiple branch transactions during the execution phase based on their execution status. Here, the execution phase can be called the commit or rollback phase, and during the commit or rollback phase, the execution decision for the multiple branch transactions during the execution phase can be either commit or rollback.

[0043] For example, if multiple branch transactions all succeed during the preparation phase, the execution decision for the execution phase is determined to be commit. If at least one branch transaction (such as the last branch transaction) fails during the preparation phase, the execution decision for the execution phase is determined to be rollback. Furthermore, when the execution decision is commit, the transaction manager releases the local locks of the multiple branch transactions. At this point, the business data of the multiple branch transactions can be read by other transactions, improving concurrency capabilities.

[0044] Based on the execution decision, the transaction manager sends a global transaction decision confirmation request to the transaction coordinator. Here, if the execution decision is to commit, the decision confirmation request is a commit confirmation request, which can be used to request the transaction coordinator to confirm the commit of the global transaction; if the execution decision is to rollback, the decision confirmation request is a rollback confirmation request, which can be used to request the transaction coordinator to confirm the rollback of the global transaction.

[0045] In response to the resolution confirmation request, the transaction coordinator determines the resolution confirmation result of the global transaction based on the execution status of multiple branch transactions during the preparation phase. Here, the resolution confirmation result can include commit and rollback. If the resolution confirmation result is commit, the transaction coordinator can send commit instructions for the execution phase of multiple branch transactions to multiple resource managers and release the global lock. That is, after confirming that all branch transactions are successfully prepared, the transaction coordinator immediately releases the global locks of all branch transactions (including global locks for order services, inventory services, and payment services) and sends commit instructions for the execution phase to multiple resource managers corresponding to multiple branch transactions. At this point, the global locks are released, and other transactions can immediately operate on the relevant resources without waiting for the execution phase (i.e., the second phase) of multiple branch transactions to complete. This greatly reduces resource locking time, significantly improving performance in scenarios where most business operations can be successfully committed, and avoiding the problem of inefficient business operation due to long-term data locking in high-concurrency and long-transaction scenarios.

[0046] In response to the commit instruction, each resource manager places the commit operation into an asynchronous queue, asynchronously commits each branch transaction according to a preset execution order, and asynchronously deletes the previously generated rollback logs. Throughout the process, even if there is a brief delay in the execution phase (second phase), it does not affect other transactions' access to data, thus improving the overall system throughput.

[0047] According to the technical solution of the exemplary embodiments of this disclosure, a transaction manager sends a registration and start request for a global transaction of the business to be executed to a transaction coordinator; the transaction coordinator, in response to the registration and start request, registers and starts the global transaction and allocates a global lock for the global transaction; the transaction manager sends a call request to each resource manager according to the preset execution order of multiple branch transactions corresponding to the global transaction; each resource manager, in response to the call request, starts the branch transaction indicated by the call request and determines the execution status of each branch transaction in the preparation phase; and sends the execution status to the transaction manager and the transaction coordinator respectively; wherein, the preparation phase includes: acquiring a local lock, constructing a rollback log, and committing the rollback log, and the execution status is used to indicate whether the preparation phase was successfully executed; the transaction manager, based on the execution status of multiple branch transactions in the preparation phase, determines the execution status of multiple branch transactions in the execution phase. The process involves several steps: First, the system executes the decision during the execution phase. Based on this decision, it sends a global transaction confirmation request to the transaction coordinator. If the execution decision is not a commit, it releases the local locks of multiple branch transactions. The transaction coordinator, responding to the confirmation request, determines the global transaction confirmation result based on the execution status of multiple branch transactions during the preparation phase. If the confirmation result is a commit, it sends commit instructions for multiple branch transactions during the execution phase to multiple resource managers and releases the global locks. Each resource manager, responding to the commit instructions, asynchronously commits each branch transaction according to a preset execution order and asynchronously deletes the rollback logs of each branch transaction. This process maintains the atomicity, consistency, isolation, and durability (ACID properties) of transactions while significantly reducing resource locking time, improving the concurrent processing capability and overall performance of the distributed transaction processing system, and ensuring efficient business operation.

[0048] In some embodiments, the invocation request carries the business execution statements for each branch transaction; constructing a rollback log may include: The call request is parsed to obtain the business execution statement of the branch transaction indicated by the call request; The target parsing mode among various preset parsing modes is used to parse the business execution statement and obtain the parsing result; Based on the parsing results, generate snapshot data for the branch transactions; Based on the business execution statements and snapshot data, generate rollback logs for branch transactions.

[0049] Specifically, the resource manager receives a call request sent by the transaction manager. Since the call request carries the business execution statement (Structured Query Language, SQL) and related parameters of the branch transaction, the resource manager can parse the call request to obtain the business execution statement of the branch transaction.

[0050] Based on the number of branch transactions corresponding to the global transaction, a target resolution mode is selected from multiple preset resolution modes. Here, the multiple preset resolution modes may include Visitor Pattern and Listener Pattern. If the number of branch transactions is greater than a preset number, the target resolution mode is Visitor Pattern; if the number of branch transactions is less than or equal to the preset number, the target resolution mode is Listener Pattern. The preset number can be set according to actual needs, and this embodiment does not specifically limit it. In the method of this embodiment, the preset number can be set to 3.

[0051] The visitor pattern executes the following steps: 1. Create a new lexical analyzer to process the SQL language; 2. Create a buffer of lexical symbols to store the lexical symbols generated by the lexical analyzer; 3. Create a new parser to process the contents of the lexical symbol buffer; 4. Start parsing the SQL Statements rules; 5. Pass the root node of the parse tree, `tree`, to the `visit` interface and traverse the parse tree.

[0052] The listener mode involves monitoring an object; if a specific event occurs on that object, the listener is triggered. Specifically, it executes the following steps: 1. Analyze the lexical structure of the character stream, parsing it into a token; 2. Analyze the token; 3. Using a listener, traverse the syntax tree, where root is the root node of the syntax tree according to the syntax definition.

[0053] By referencing the number of transactions in multiple branches, the SQL parsing mode is determined, making the SQL parsing mode adaptable to the current amount of SQL to be parsed, thus speeding up the SQL parsing efficiency.

[0054] After acquiring the local lock, the resource manager queries the current data status based on the conditions in the parsed results, generates snapshot data, combines the snapshot data and SQL-related information into a rollback log, commits the business SQL and the rollback log in the same local branch transaction, and then releases the local lock and connection resources, achieving the lowest level row-level lock and fast resource release.

[0055] In some embodiments, the method may further include: The transaction manager obtains the historical execution success rate of multiple branch transactions within a preset historical time period; if the historical execution success rate of multiple branch transactions is greater than or equal to the first preset execution success rate, it determines that the execution status of each branch transaction in the preparation phase is successful; and sends the first registration request of each branch transaction to each resource manager. In response to the first registration request, each resource manager requests the transaction coordinator to register each branch transaction and requests the transaction coordinator to record that the execution status of each branch transaction during the preparation phase is successful.

[0056] Specifically, the aforementioned preset historical time period can be the most recent historical time period. The preset duration of this historical time period can be selected according to actual needs, and this embodiment does not impose a specific limitation on it. In the method of this embodiment, the preset historical time period can be the past 20 minutes.

[0057] The success rate of branch transaction execution can refer to the success rate of the preparation phase of the branch transaction, or the success rate of the branch transaction operation completion. By judging the success rate, the order of execution and reporting can be determined, enabling rapid execution.

[0058] The aforementioned first preset execution success rate can be set according to actual needs, and this disclosure embodiment does not specifically limit it. In the method of this disclosure embodiment, the first preset execution success rate is set to 100%, 99%, or 95%.

[0059] After the transaction coordinator starts a global transaction, the transaction manager can obtain the historical execution success rate of multiple branch transactions corresponding to the global transaction within a preset historical time period (the past 20 minutes), and then compare the historical execution success rate with a first preset execution success rate (e.g., 100%). If the historical execution success rate of multiple branch transactions is equal to 100%, it is predicted that the preparation phase of each branch transaction in the multiple branch transactions will be successfully executed. At this time, it can be determined that the execution status of each branch transaction in the preparation phase of the multiple branch transactions is successful. Without waiting for each resource manager to actually execute the preparation phase of each branch transaction in the multiple branch transactions, the first registration request of each branch transaction can be sent to each resource manager.

[0060] Each resource manager responds to the first registration request, requesting the transaction coordinator to register each branch transaction and record that the execution status of each branch transaction during the preparation phase was successful. Then, step S305 is executed. This method shortens the time required between the successful completion of the preparation phase for all branch transactions, the submission of a global transaction resolution confirmation request to the transaction coordinator, and the subsequent wait for the transaction coordinator's commit instruction. It allows for rapid entry into the execution phase, saving overall process time and improving operational efficiency.

[0061] In some embodiments, the method may further include: If the historical execution success rate of multiple branch transactions is less than the first preset execution success rate but greater than or equal to the second preset execution success rate, the transaction manager sends the second registration request for each branch transaction and the execution request for each branch transaction in the preparation phase to each resource manager. Each resource manager responds to the second registration request by requesting the transaction coordinator to register each branch transaction; responds to the execution request by executing the preparation phase of each branch transaction to determine the execution status of each branch transaction during the preparation phase; and sends the execution status to the transaction coordinator.

[0062] Specifically, the aforementioned second preset execution success rate can be set according to actual needs, and this disclosure embodiment does not impose specific limitations on it. In the method of this disclosure embodiment, the second preset execution success rate is set to 90%.

[0063] If the historical execution success rate of multiple branch transactions is less than 100% but greater than or equal to 90%, it is predicted that the preparation phase of each branch transaction will be successfully executed. At this time, the second registration request of each branch transaction and the execution request of each branch transaction in the preparation phase can be sent to each resource manager.

[0064] Each resource manager can respond to the second registration request and request the transaction coordinator to register each branch transaction. At this time, although the execution status of the multiple branch transactions corresponding to the global transaction in the preparation phase cannot be determined, since the historical execution success rate of the multiple branch transactions within the preset historical time period is still relatively high, it can request the transaction coordinator to register all branch transactions corresponding to the global transaction, and then wait for confirmation of the execution status of each branch transaction in the preparation phase.

[0065] Each resource manager can respond to an execution request by performing the preparation phase of its respective branch transaction to determine the execution status of each branch transaction during the preparation phase, and then send the execution status to the transaction coordinator. Upon receiving the execution status, the transaction coordinator records that status for each registered branch transaction. Based on this, the transaction coordinator can save time registering multiple branch transactions corresponding to a local transaction.

[0066] For example, the transaction manager can also obtain the execution status of multiple branch transactions corresponding to the global transaction within a preset historical time period, and determine whether there are any execution failures in the execution status of the multiple branch transactions within the preset historical time period.

[0067] If multiple branch transactions have all been successfully executed within a preset historical time period, a first registration request for each branch transaction is sent to each resource manager. Each resource manager responds to the first registration request by requesting the transaction coordinator to register each branch transaction and to record that the execution status of each branch transaction during the preparation phase was successful. For detailed analysis, please refer to the preceding text; it will not be repeated here.

[0068] If multiple branch transactions fail to execute within a preset historical time period, a second registration request for each branch transaction and an execution request for the preparation phase of each branch transaction are sent to each resource manager. Each resource manager responds to the second registration request by requesting the transaction coordinator to register each branch transaction; responds to the execution request by executing the preparation phase of each branch transaction to determine its execution status during the preparation phase; and sends the execution status to the transaction coordinator. For detailed analysis, please refer to the preceding text; it will not be repeated here.

[0069] Based on this, if the preparation phase of a branch transaction fails, a retry process begins until it succeeds.

[0070] Based on the above registration scheme, while ensuring the success rate of branch transaction execution, it can promote the rapid entry of branch transactions into the execution phase (second phase), saving the time used in the entire process, improving business processing efficiency, and thus enhancing the concurrent processing capability and overall performance of the distributed transaction processing system.

[0071] In some embodiments, the method may further include: If the transaction coordinator confirms the decision to roll back, it sends rollback instructions for multiple branch transactions during the execution phase to multiple resource managers. Each resource manager responds to the rollback instruction, rolls back each branch transaction based on the rollback log of each branch transaction, determines the rollback result of each branch transaction, and sends the rollback result to the transaction coordinator. The transaction coordinator receives the rollback results from each branch transaction and releases the global lock if the rollback results of multiple branch transactions are all successful.

[0072] Specifically, if at least one branch transaction (such as the last branch transaction) fails during the preparation phase, the execution decision for all branch transactions during the execution phase is to roll back. In other words, if any branch transaction fails to prepare, a global rollback decision is triggered. Based on the execution decision, the transaction manager sends a global transaction rollback confirmation request to the transaction coordinator. In response to the rollback confirmation request, the transaction coordinator determines the global transaction's decision to roll back based on the execution status of the multiple branch transactions during the preparation phase.

[0073] If the transaction coordinator confirms the rollback decision, it sends rollback instructions for multiple branch transactions during the execution phase to multiple resource managers. Each resource manager responds to the rollback instructions, rolls back each branch transaction based on the rollback log of each branch transaction, determines the rollback result of each branch transaction, and sends the rollback result to the transaction coordinator.

[0074] For example, when registering a global transaction and multiple branch transactions, the transaction coordinator can assign a global transaction identifier (XID) to the global transaction and branch transaction identifiers (Branch IDs) to each branch transaction, and associate the global transaction identifier with the multiple branch transaction identifiers. The rollback log of each branch transaction contains both the global transaction identifier and the branch transaction identifier of that branch transaction.

[0075] Upon receiving a rollback instruction, each resource manager can retrieve the before-and after snapshot data of the relevant data in the branch transaction from the rollback log using the global transaction identifier and the branch transaction identifier. The after-and after snapshot data is compared with the current record in the local database. If they match, the data in the before-and after snapshot is used to overwrite the current record. If the after-and after snapshot does not match the current record in the local database, a dirty rollback is considered to have occurred, requiring manual intervention to prevent data corruption and ensure eventual consistency. Finally, the rollback result of the branch transaction is reported to the transaction coordinator.

[0076] The transaction coordinator receives the rollback results from each branch transaction and releases the global lock if the rollback results of multiple branch transactions are all successful, ensuring data isolation during the rollback process.

[0077] Based on this, the embodiments of this disclosure can ensure that even if the preparation phase of any branch transaction fails, it can still be safely restored to a consistent state. At the same time, by holding a global lock until the rollback is complete, data races during the rollback process are prevented.

[0078] Figure 4 A schematic diagram of the resource locking process in distributed transaction processing provided by related technologies is shown. Figure 5 A schematic diagram illustrating a resource locking process for distributed transaction processing provided in an exemplary embodiment of this disclosure is shown. Figure 4 In the related technologies shown, regardless of whether the global transaction's resolution result is a commit or a rollback, transactional resources must be retained until the second phase is completed before they can be released. For example... Figure 5As shown in this embodiment, the local lock on data within a branch transaction is managed by the local branch transaction and released at the end of the first phase of the branch transaction. The global lock on data within a branch transaction is managed by the transaction coordinator and can be released immediately when the second phase global commit is decided.

[0079] As can be seen, in related technologies, regardless of whether the final decision of the global transaction in the second phase is commit or rollback, the resource manager can only release resources after all transactions have been committed or rolled back globally. However, in this embodiment, if the final decision of the global transaction in the second phase is commit, the global lock can be released immediately without waiting for the second phase to end. When multiple branch transactions execute in parallel, in the first phase, i.e., the preparation phase, if all branch transactions receive a commit instruction, the global lock is released immediately, without needing to wait until all branch transactions have successfully committed before releasing the global lock. Only in the case of a global rollback is the global lock held until the end of the second phase of the branch. This design greatly reduces resource locking time, significantly improving performance in scenarios where most business operations can be successfully committed, and avoiding the problem of data being locked for a long time in high-concurrency and long-transaction scenarios, leading to inefficient business operation. Compared with related technologies, this embodiment greatly reduces the resource locking time of branch transactions, providing a foundation for improving overall concurrency and throughput.

[0080] In some embodiments, if conflicting branch transactions exist among multiple branch transactions, and the conflicting branch transaction conflicts with one of the other branch transactions among multiple other branch transactions corresponding to other global transactions to be rolled back, the rollback instruction carries the rollback order flags of the conflicting branch transaction and the other branch transactions that conflict with the conflicting branch transaction; the method may further include: The transaction coordinator uses a preset priority division rule to determine the rollback priority of conflicting branch transactions and other branch transactions that conflict with the conflicting branch transactions; it sorts the rollback priorities in ascending order to determine the rollback order markers of conflicting branch transactions and other branch transactions that conflict with the conflicting branch transactions. In response to a rollback instruction, the resource manager marks the rollback order according to the indicated rollback order and rolls back the conflicting branch transactions based on the rollback log of the conflicting branch transactions.

[0081] Specifically, when the transaction coordinator decides to roll back two global transactions (the current global transaction TX_A and other global transactions TX_B), it finds that both global transactions contain branch transactions that operate on the same product (ID: 1001) inventory (the conflicting branch transaction Branch_A_Stock and another branch transaction Branch_B_Stock that conflicts with the conflicting branch transaction).

[0082] The transaction coordinator determines priority based on a preset priority ranking rule (e.g., according to the start timestamp of global transactions, with smaller timestamps indicating higher priority): global transaction TX_A starts at 10:00:00.000, while other global transactions, such as TX_B, start at 10:00:00.020. Therefore, TX_A has a higher priority than TX_B. In rollback conflict handling, higher-priority transactions are rolled back later to ensure their data state is ultimately valid and to minimize the impact on higher-priority transactions. Therefore, the rollback order is determined as follows: first roll back other branch transactions in TX_B that conflict with the conflicting branch transaction, then roll back the conflicting branch transactions in TX_A. This process ensures that high-priority transactions are processed first, thereby improving the overall efficiency and response speed of the system.

[0083] Based on this, the transaction coordinator determines a rollback instruction according to the rollback order and sends this instruction to the resource manager corresponding to the conflicting branch transaction. In response to the rollback instruction, the resource manager marks the rollback order according to the indicated order and performs a rollback operation on the conflicting branch transaction based on its rollback log, changing the status of the conflicting branch transaction from "active" to "rollback". After the rollback operation is complete, the distributed transaction processing system unlocks relevant resources, including database locks and other resources that may have been held by transactions. Finally, the distributed transaction processing system allows higher-priority transactions to continue execution, occupying the previously released resources.

[0084] Based on this, the resource manager performs sequential rollback on conflicting resources to avoid data state chaos caused by cross rollbacks, effectively solving the resource conflict problem during concurrent rollback of distributed transactions. While ensuring data consistency, it achieves determinism and orderliness in the rollback process.

[0085] For non-conflicting branch transactions among the multiple branch transactions corresponding to a global transaction, since they do not involve conflicting resources, they are executed concurrently immediately after their corresponding resource managers receive the rollback instruction, without waiting for the rollback order.

[0086] In addition, the resource manager can also time the rollback process; if the rollback time exceeds the preset time, it will send a prompt message to the operation and maintenance personnel and generate a rollback log to facilitate their inspection. Here, the preset time can be set according to actual needs, and this embodiment does not impose a specific limitation on it.

[0087] The foregoing mainly describes the solutions provided by the embodiments of this disclosure. It is understood that, in order to achieve the above functions, the electronic device includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein, this disclosure can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this disclosure.

[0088] This disclosure embodiment can divide the electronic device into functional units according to the above method example. For example, each function can be divided into a separate functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this disclosure embodiment is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.

[0089] By dividing each functional module according to its corresponding functions, an exemplary embodiment of this disclosure provides a distributed transaction processing system, including a transaction coordinator, a transaction manager, and multiple resource managers; The transaction manager is configured to send a registration and start request for a global transaction for the business to be executed to the transaction coordinator; The transaction coordinator is configured to register and start the global transaction in response to the registration and start request, and to allocate a global lock for the global transaction; The transaction manager is configured to send call requests to each of the resource managers according to the preset execution order of the multiple branch transactions corresponding to the global transaction; Each of the resource managers is configured to respond to the call request, start the branch transaction indicated by the call request, and determine the execution status of each branch transaction in the preparation phase; and send the execution status to the transaction manager and the transaction coordinator respectively; wherein, the preparation phase includes: acquiring a local lock, constructing a rollback log, and committing the rollback log, and the execution status is used to indicate whether the preparation phase was executed successfully; The transaction manager is configured to determine the execution resolution of the multiple branch transactions in the execution phase based on the execution status of the multiple branch transactions in the preparation phase; send a resolution confirmation request for the global transaction to the transaction coordinator based on the execution resolution; and release the local locks of the multiple branch transactions if the execution resolution is a commit. The transaction coordinator is configured to, in response to the resolution confirmation request, determine the resolution confirmation result of the global transaction based on the execution status of the multiple branch transactions in the preparation phase; if the resolution confirmation result is a commit, send a commit instruction of the multiple branch transactions in the execution phase to the multiple resource managers, and release the global lock; Each of the resource managers is configured to, in response to the commit instruction, asynchronously commit each of the branch transactions in a preset execution order, and asynchronously delete the rollback logs of each of the branch transactions.

[0090] In some embodiments, the transaction manager is configured to obtain the historical execution success rate of the plurality of branch transactions within a preset historical time period; if the historical execution success rate of the plurality of branch transactions is greater than or equal to a first preset execution success rate, determine that the execution status of each of the plurality of branch transactions in the preparation phase is successful; and send a first registration request for each of the branch transactions to each of the resource managers. Each of the resource managers is configured to, in response to the first registration request, request the transaction coordinator to register each of the branch transactions, and request the transaction coordinator to record that the execution status of each of the branch transactions in the preparation phase is successful.

[0091] In some embodiments, the transaction manager is configured to send a second registration request for each branch transaction and an execution request for each branch transaction in the preparation phase to each of the resource managers when the historical execution success rates of the plurality of branch transactions are all less than a first preset execution success rate and greater than or equal to a second preset execution success rate. Each of the resource managers is configured to, in response to the second registration request, request the transaction coordinator to register each of the branch transactions; in response to the execution request, execute the preparation phase of each of the branch transactions to determine the execution status of each of the branch transactions in the preparation phase; and send the execution status to the transaction coordinator.

[0092] In some embodiments, the transaction coordinator is configured to send rollback instructions for the multiple branch transactions during the execution phase to the multiple resource managers if the resolution confirmation result is rollback; Each of the resource managers is configured to, in response to the rollback instruction, roll back each of the branch transactions based on the rollback logs of each of the branch transactions, determine the rollback result of each of the branch transactions, and send the rollback result to the transaction coordinator; The transaction coordinator is configured to receive the rollback results of each of the branch transactions, and release the global lock if the rollback results of all the branch transactions are successful.

[0093] In some embodiments, if there are conflicting branch transactions among the plurality of branch transactions, the conflicting branch transaction conflicts with one of the other branch transactions among the plurality of other branch transactions corresponding to other global transactions to be rolled back, and the rollback indication carries the rollback order flags of the conflicting branch transaction and the other branch transactions that conflict with the conflicting branch transaction. The transaction coordinator is configured to determine the rollback priority of the conflicting branch transaction and other branch transactions that conflict with the conflicting branch transaction using a preset priority division rule; and to sort the rollback priorities in ascending order to determine the rollback order marker of the conflicting branch transaction and other branch transactions that conflict with the conflicting branch transaction. The resource manager is configured to, in response to the rollback instruction, roll back the conflicting branch transactions according to the rollback order indicated by the rollback order marking, based on the rollback log of the conflicting branch transactions.

[0094] In some embodiments, the call request carries the business execution statements of each branch transaction; each resource manager is configured to parse the call request to obtain the business execution statements of the branch transactions indicated by the call request; the business execution statements are parsed using a target parsing mode among multiple preset parsing modes to obtain parsing results; snapshot data of the branch transactions is generated based on the parsing results; and rollback logs of the branch transactions are generated based on the business execution statements and the snapshot data.

[0095] Exemplary embodiments of this disclosure also provide an electronic device including a distributed transaction processing system that executes a computer program, which, when executed by the distributed transaction processing system, causes the electronic device to perform a method according to an embodiment of this disclosure.

[0096] Exemplary embodiments of this disclosure also provide a non-transitory computer-readable storage medium storing a computer program, wherein the computer program, when executed by a computer's processor, is used to cause the computer to perform a method according to embodiments of this disclosure.

[0097] Figure 6 A schematic diagram of a computer program product provided in an exemplary embodiment of this disclosure is shown, such as... Figure 6As shown, an exemplary embodiment of this disclosure also provides a computer program product 600, including a computer program 601, wherein the computer program, when executed by a computer's processor, is used to cause the computer to perform a method according to an embodiment of this disclosure.

[0098] refer to Figure 7 The following is a structural block diagram of an electronic device 700 that can serve as a distributed transaction processing system of the present disclosure, which is an example of a hardware device that can be applied to various aspects of the present disclosure. Figure 7 A hardware block diagram of an electronic device provided with exemplary embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of servers, such as a standalone physical server, a server cluster or distributed system consisting of multiple physical servers, a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0099] like Figure 7 As shown, the electronic device 700 includes a computing unit 701, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 702 or a computer program loaded from a storage unit 708 into a random access memory (RAM) 703. The RAM 703 may also store various programs and data required for the operation of the electronic device 700. The computing unit 701, ROM 702, and RAM 703 are interconnected via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0100] Multiple components in electronic device 700 are connected to I / O interface 705, including: input unit 706, output unit 707, storage unit 708, and communication unit 709. Input unit 706 can be any type of device capable of inputting information to electronic device 700. Input unit 706 can receive input digital or character information and generate key signal inputs related to user settings and / or function control of electronic device. Output unit 707 can be any type of device capable of presenting information and may include, but is not limited to, a display, speaker, video / audio output terminal, vibrator, and / or printer. Storage unit 708 may include, but is not limited to, disk and optical disk. Communication unit 709 allows electronic device 700 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks, and may include, but is not limited to, modems, network cards, infrared communication devices, wireless communication transceivers, and / or chipsets, such as Bluetooth™ devices, WiFi devices, WiMax devices, cellular communication devices, and / or the like.

[0101] The computing unit 701 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 701 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 701 performs the various methods and processes described above. For example, in some embodiments, the methods of the exemplary embodiments of this disclosure can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 708. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 700 via ROM 702 and / or communication unit 709. In some embodiments, the computing unit 701 can be configured to perform the methods of the exemplary embodiments of this disclosure by any other suitable means (e.g., by means of firmware).

[0102] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0103] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0104] As used in this disclosure, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, device, and / or apparatus (e.g., disk, optical disk, memory, programmable logic device (PLD)) for providing machine instructions and / or data to a programmable processor, including machine-readable media that receive machine instructions as machine-readable signals. The term "machine-readable signal" refers to any signal for providing machine instructions and / or data to a programmable processor.

[0105] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0106] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0107] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed on a computer, the processes or functions described in the embodiments of this disclosure are performed entirely or partially. The computer can be a general-purpose computer, a special-purpose computer, a computer network, a terminal, a user equipment, or other programmable device. The computer program or instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, the computer program or instructions can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; it can also be an optical medium, such as a digital video disc (DVD); or it can be a semiconductor medium, such as a solid-state drive (SSD).

[0108] Although this disclosure has been described in conjunction with specific features and embodiments, it will be apparent that various modifications and combinations can be made therein without departing from the spirit and scope of this disclosure. Accordingly, this specification and drawings are merely exemplary illustrations of the disclosure as defined by the appended claims and are to be considered as covering any and all modifications, variations, combinations, or equivalents within the scope of this disclosure. It is obvious that those skilled in the art can make various alterations and modifications to this disclosure without departing from its spirit and scope. Thus, this disclosure is also intended to include any such modifications and modifications that fall within the scope of the claims of this disclosure and their equivalents.

Claims

1. A distributed transaction processing method, characterized in that, The method is applied to a distributed transaction processing system, which includes a transaction coordinator, a transaction manager, and multiple resource managers; the method includes: The transaction manager sends a registration and start request for the global transaction of the business to be executed to the transaction coordinator; The transaction coordinator responds to the registration and start request by registering and starting the global transaction and allocating a global lock for the global transaction. The transaction manager sends call requests to each of the resource managers according to the preset execution order of the multiple branch transactions corresponding to the global transaction; Each of the resource managers responds to the call request, starts the branch transaction indicated by the call request, and determines the execution status of each branch transaction in the preparation phase; the execution status is sent to the transaction manager and the transaction coordinator respectively; wherein, the preparation phase includes: acquiring a local lock, constructing a rollback log, and committing the rollback log, and the execution status is used to indicate whether the preparation phase was executed successfully; The transaction manager determines the execution resolution of the multiple branch transactions in the execution phase based on the execution status of the multiple branch transactions in the preparation phase; based on the execution resolution, it sends a resolution confirmation request for the global transaction to the transaction coordinator; and if the execution resolution is a commit, it releases the local locks of the multiple branch transactions. In response to the resolution confirmation request, the transaction coordinator determines the resolution confirmation result of the global transaction based on the execution status of the multiple branch transactions in the preparation phase; if the resolution confirmation result is a commit, the coordinator sends a commit instruction of the multiple branch transactions in the execution phase to the multiple resource managers and releases the global lock. In response to the commit instruction, each of the resource managers asynchronously commits each of the branch transactions according to a preset execution order, and asynchronously deletes the rollback logs of each of the branch transactions.

2. The method as described in claim 1, characterized in that, The method further includes: The transaction manager obtains the historical execution success rate of the multiple branch transactions within a preset historical time period; if the historical execution success rate of the multiple branch transactions is greater than or equal to the first preset execution success rate, it determines that the execution status of each of the multiple branch transactions in the preparation stage is successful; and sends the first registration request of each branch transaction to each of the resource managers. In response to the first registration request, each of the resource managers requests the transaction coordinator to register each of the branch transactions and requests the transaction coordinator to record that the execution status of each of the branch transactions in the preparation phase is successful.

3. The method as described in claim 2, characterized in that, The method further includes: When the historical execution success rate of the multiple branch transactions is less than the first preset execution success rate and greater than or equal to the second preset execution success rate, the transaction manager sends the second registration request of each branch transaction and the execution request of each branch transaction in the preparation phase to each of the resource managers. In response to the second registration request, each of the resource managers requests the transaction coordinator to register each of the branch transactions; in response to the execution request, each of the branch transactions performs the preparation phase to determine the execution status of each of the branch transactions in the preparation phase; and sends the execution status to the transaction coordinator.

4. The method as described in claim 1, characterized in that, The method further includes: If the resolution confirmation result is rollback, the transaction coordinator sends rollback instructions for the multiple branch transactions during the execution phase to the multiple resource managers. In response to the rollback instruction, each resource manager rolls back each branch transaction based on the rollback log of each branch transaction, determines the rollback result of each branch transaction, and sends the rollback result to the transaction coordinator. The transaction coordinator receives the rollback results of each branch transaction, and releases the global lock if the rollback results of all the branch transactions are successful.

5. The method as described in claim 4, characterized in that, If there are conflicting branch transactions among the multiple branch transactions, and the conflicting branch transaction conflicts with one of the other branch transactions corresponding to other global transactions to be rolled back, the rollback indication carries the rollback order flags of the conflicting branch transaction and the other branch transactions that conflict with the conflicting branch transaction. The method further includes: The transaction coordinator uses a preset priority division rule to determine the rollback priority of the conflicting branch transaction and other branch transactions that conflict with the conflicting branch transaction; and sorts the rollback priorities in ascending order to determine the rollback order marker of the conflicting branch transaction and other branch transactions that conflict with the conflicting branch transaction. In response to the rollback instruction, the resource manager rolls back the conflicting branch transactions according to the rollback order indicated by the rollback order mark, based on the rollback log of the conflicting branch transactions.

6. The method according to any one of claims 1 to 5, characterized in that, The call request carries the business execution statements for each branch transaction; the construction of the rollback log includes: The call request is parsed to obtain the business execution statement of the branch transaction indicated by the call request; The business execution statement is parsed using the target parsing mode from a variety of preset parsing modes to obtain the parsing result; Based on the parsing results, snapshot data of the branch transaction is generated; Based on the business execution statement and the snapshot data, the rollback log of the branch transaction is generated.

7. A distributed transaction processing system, characterized in that, This includes a transaction coordinator, a transaction manager, and multiple resource managers; The transaction manager is configured to send a registration and start request for a global transaction for the business to be executed to the transaction coordinator; The transaction coordinator is configured to register and start the global transaction in response to the registration and start request, and to allocate a global lock for the global transaction; The transaction manager is configured to send call requests to each of the resource managers according to the preset execution order of the multiple branch transactions corresponding to the global transaction; Each of the resource managers is configured to, in response to the call request, initiate the branch transaction indicated by the call request, and determine the execution status of each branch transaction during the preparation phase; The execution status is sent to the transaction manager and the transaction coordinator respectively; wherein, the preparation phase includes: acquiring a local lock, constructing a rollback log, and committing the rollback log, and the execution status is used to indicate whether the preparation phase was executed successfully; The transaction manager is configured to determine the execution resolution of the multiple branch transactions in the execution phase based on the execution status of the multiple branch transactions in the preparation phase; send a resolution confirmation request for the global transaction to the transaction coordinator based on the execution resolution; and release the local locks of the multiple branch transactions if the execution resolution is a commit. The transaction coordinator is configured to, in response to the resolution confirmation request, determine the resolution confirmation result of the global transaction based on the execution status of the multiple branch transactions in the preparation phase; if the resolution confirmation result is a commit, send a commit instruction of the multiple branch transactions in the execution phase to the multiple resource managers, and release the global lock; Each of the resource managers is configured to, in response to the commit instruction, asynchronously commit each of the branch transactions in a preset execution order, and asynchronously delete the rollback logs of each of the branch transactions.

8. An electronic device, characterized in that, Includes the distributed transaction processing system as described in claim 7, wherein the distributed transaction processing system executes a computer program to implement the steps of the method as described in any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps of the method described in any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the steps of the method described in any one of claims 1 to 6.

Images