Lock-free distributed transaction coordinator for in-memory database participants

Abstract

Methods, systems, apparatus, and computer program products for coordinating distributed database transactions are provided. A transaction driver, such as a client machine, can initiate a distributed transaction. The transaction driver can send a driver report to a transaction coordinator, the driver report including identification information related to the distributed transaction, including identification of the participants participating in the transaction. The coordinator can determine whether a participant report is received from each of the participants, the participant report including the status of a portion of the distributed database transaction for a particular participant. The participant report can also identify participants that are descendants of the reporting participant. The transaction coordinator can store information in a table to track the progress of the distributed transaction. Using the table, the result of the distributed transaction can be determined and sent to one or more of the involved participants.

Description

Background Art

[0001] Database transactions can span many forms and involve a variety of different databases. For example, a local transaction on a database may include operations that can be performed in a single database. In some other instances, transactions can be performed across multiple databases, also known as distributed transactions. In a distributed transaction, each database participating in the transaction can maintain its own transaction log that is independent of the transaction logs of other databases. For example, where several independent databases are part of a larger cloud-based system, each database participating in the distributed transaction can perform a specific part of the distributed transaction separately and record each event separately in the transaction log.

[0002] However, in some distributed transactions, there may be dependencies between multiple databases participating in the transaction, such that operations performed across all of the databases involved may need to be performed atomically. For example, a particular transaction may require multiple databases to perform portions of a desired task. In the event that one or more databases are offline, restarted, crashed, or otherwise fail to perform a particular portion of a distributed transaction, one database may fail to perform its portion of the transaction while the other databases successfully perform their operations. As a result, consistency issues may result, such as different portions of the same transaction being unnecessarily placed in a pending or aborted state, database corruption, data mismatches, and the like. Summary of the invention

[0003] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter.

[0004] Methods, systems, devices, and computer program products for coordinating distributed database transactions are provided. A transaction driver, such as a client machine, can initiate a distributed transaction. The transaction driver can send a driver report to a transaction coordinator, the driver report including a global identifier of the distributed database transaction, a transaction driver identifier, and a participant identifier, the participant identifier indicating the participant responsible for the portion of the distributed database transaction. The coordinator can determine whether a participant report is received from each of the participants, the participant report including the state of the portion of the distributed database transaction of the specific participant and other things. In some cases, the received participant report can identify one or more descendant participant identifiers that are descendants of the reporting participant. The transaction coordinator can store the global identifier, the participant identifier, any descendant participant identifiers in a table and store the state of the portion of the distributed database transaction of the reporting entity for each of the participants that sent the participant report. Using the table, the result of the distributed transaction can be determined and sent to one or more of the involved participants.

[0005] In the above manner, the transaction coordinator is enabled to track the status and / or progress of distributed transactions involving multiple participants. For example, if any of the participants aborts its corresponding part of the distributed transaction, the coordinator can determine that the transaction will be aborted for all of the participants involved, so that the transaction is recorded in the coordinator's persistent table as an aborted transaction. Similarly, if each of the reporting participants commits the distributed transaction, the transaction coordinator can determine that the distributed transaction is fully committed by all of the involved participants, thereby committing the transaction as a whole and enabling the transaction to be stored in the coordinator's persistent table and / or be clear in the transaction log of each participant. In this way, the transaction coordinator can ensure that the transaction is executed (or not executed) atomically in an appropriate manner.

[0006] Other features and advantages of the present invention and the structure and operation of various embodiments are described in detail below with reference to the accompanying drawings. It should be noted that the present invention is not limited to the specific embodiments described herein. Such embodiments are proposed herein only for illustrative purposes. Based on the teachings contained herein, other embodiments will become apparent to those skilled in the relevant art(s). BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate embodiments of the present application and, together with the description, further serve to explain the principles of the embodiments and enable those skilled in the relevant art to make and use the embodiments.

[0008] Figure 1A block diagram of a distributed transaction coordination system according to an example embodiment is shown.

[0009] Figure 2 A flow chart of a method for coordinating distributed transactions involving multiple database participants according to an example embodiment is shown.

[0010] Figure 3 A block diagram of a coordination system for coordinating distributed transactions according to an example embodiment is shown.

[0011] FIG. 4A to FIG. 4B A block diagram depicting coordination of distributed transactions according to an example embodiment is shown.

[0012] Figure 5 A flow chart of a method for processing a request for results of a distributed transaction of participants is shown according to an example embodiment.

[0013] Figure 6 A flow chart of a method for processing a descendant participant report received from a descendant participant according to an example embodiment is shown.

[0014] Figure 7 A block diagram of an example computing device is shown that may be used to implement example embodiments.

[0015] Features and advantages of the present invention will become more apparent from the detailed description set forth below in conjunction with the accompanying drawings, in which the same reference numerals identify corresponding elements throughout. In the accompanying drawings, the same reference numerals generally indicate identical, functionally similar, and / or structurally similar elements. The drawing in which an element first appears is indicated by the leftmost digit(s) in the corresponding reference numeral. DETAILED DESCRIPTION

[0016] I. Introduction

[0017] This specification and the accompanying drawings disclose one or more embodiments incorporating the features of the present invention. The scope of the present invention is not limited by the disclosed embodiments. The disclosed embodiments merely illustrate the present invention, and modified versions of the disclosed embodiments are also covered by the present invention. The embodiments of the present invention are defined by the appended claims.

[0018] References in the specification to "one embodiment," "an embodiment," "an example embodiment," etc. indicate that the described embodiment may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases do not necessarily refer to the same embodiment. Further, when a particular feature, structure, or characteristic is described in conjunction with an example embodiment, it is considered that it is within the knowledge of a person skilled in the art to implement such feature, structure, or characteristic in conjunction with other embodiments, whether or not explicitly described.

[0019] In the discussion, unless otherwise stated, adjectives such as "substantially" and "approximately" modifying conditions or relational characteristics of one or more features of the example embodiments of the present disclosure are understood to mean that the conditions or characteristics are defined to be within acceptable tolerances for the operation of the embodiment for the application for which the embodiment is intended.

[0020] Several exemplary embodiments are described below. It should be noted that any section / subsection headings provided herein are not intended to be limiting. Embodiments are described throughout this article, and any type of embodiment may be included under any section / subsection. In addition, the embodiments disclosed in any section / subsection may be combined in any manner with any other embodiments described in the same section / subsection and / or different sections / subsections.

[0021] II. Example Implementation

[0022] Database transactions can span many forms and involve a variety of different databases. For example, a local transaction on a database may include operations that can be performed in a single database. In some other instances, transactions can be performed across multiple databases, also known as distributed transactions. In a distributed transaction, each database participating in the transaction can maintain its own transaction log that records database events that are independent of other database transaction logs. For example, where several independent databases are part of a larger cloud-based system, each database participating in a distributed transaction can separately perform a specific part of the distributed transaction and record each event separately in a transaction log, which can include one or more files in the database that record the transaction and the database modifications performed by each transaction.

[0023] However, in some distributed transactions, there may be dependencies between multiple databases participating in the transaction, such that operations performed across all of the databases involved may need to be performed atomically. For example, a particular transaction may require multiple databases to perform portions of a desired task. In the event that one or more databases are offline, restarted, crashed, or otherwise fail to perform a particular portion of a distributed transaction, one database may fail to perform its portion of the transaction while the other databases successfully perform their operations. As a result, consistency issues may result, such as different portions of the same transaction being unnecessarily placed in a pending or aborted state, database corruption, data mismatches, and the like.

[0024] Embodiments described herein address these and other problems by providing a transaction coordinator configured to coordinate distributed transactions initiated by a transaction driver. The transaction driver may send a report including a global identifier of the transaction, a transaction driver identifier, and a participant identifier, the participant identifier identifying each descendant of the transaction driver involved in the distributed transaction. For example, the transaction driver may identify each participant responsible for a separate portion of the distributed transaction. The transaction driver may also be configured to send a request indicating the corresponding role of each participant in the distributed transaction to each participant in the participants before, after, or simultaneously with sending the report to the coordinator. The transaction coordinator may receive a report from one or more of the participants, the report identifying, among other things, the status of a portion of the distributed transaction of the participant. The status may include, for example, an indication that the participant has submitted the transaction or has aborted the transaction. The coordinator may track the progress of the transaction by storing the information of each received report in a lock-free data structure, the lock-free data structure including, but not limited to, a hash table, etc. Using the table, the transaction coordinator may determine the outcome of the entire distributed transaction, such as whether the transaction is fully submitted or should be aborted by all the involved participants.

[0025] Coordinating distributed transactions in this manner has many advantages. For example, a transaction coordinator can be configured to receive reports from a transaction driver and any identified participants in any order. For example, if a participant identifies itself as an entity participating in a particular distributed transaction before the coordinator receives a report identifying the distributed transaction from the transaction driver, the coordinator can be configured to dynamically build a structure in a table containing a global identifier for the transaction and the identity of the reporting participant while waiting for reports from other involved entities (e.g., transaction driver, other participants, etc.). Therefore, regardless of the order in which the coordinator receives the reports, the transaction coordinator can be enabled to initiate tracking of the state of the distributed transaction, thereby enabling the coordinator to manage such transactions more efficiently. In this way, a database system including such a transaction coordinator can be enabled to better manage distributed transactions and allow transactions to be ensured to be executed in an atomic manner.

[0026] In addition, a database system including a transaction coordinator described herein can be enabled to manage distributed transactions in a decentralized manner. For example, if a transaction coordinator crashes or restarts during the execution of a distributed transaction (which can cause the transaction coordinator to lose a dynamically generated table that identifies information related to the transaction), then pending transaction information can still be reconstructed. For example, a transaction driver and / or any party participating in a transaction can automatically resend a report to the transaction driver when a network error or timeout error occurs (e.g., such as when the driver or party fails to receive a response from the coordinator), so that the coordinator can regenerate a table for distributed transactions. Similarly, if any particular party crashes, then the party can determine whether any distributed transaction in the party's transaction log is currently in a pending state. For each such transaction, the party can resend a report identifying the transaction to the transaction coordinator or send a request for the state of the transaction. Therefore, distributed transactions can be coordinated with automatic recovery capabilities in a decentralized manner in the event of one or more system failures, thereby further improving the database system.

[0027] Example implementations are described below, and these example implementations relate to techniques for coordinating distributed database transactions. For example, Figure 1 1 shows a block diagram of an example distributed transaction coordination system 100 according to an example embodiment. Figure 1 As shown in , system 100 includes server 102, servers 103A to 103N, and computing device 112 that are communicatively coupled via network 110. Server 102 includes control database 104. Servers 103A to 103N include databases 108A to 108N, respectively. Computing device 112 includes transaction driver 114. Control database 104 includes transaction coordination system 106. Transaction coordination system 106 is configured to control and / or manage distributed database transactions. In some implementations, such distributed database transactions may include transactions involving control database 104 and / or one or more of databases 108A to 108N. System 100 is further described as follows.

[0028] The network 110 may include one or more of a local area network (LAN), a wide area network (WAN), a personal area network (PAN), and / or a combination of communication networks (such as the Internet). The computing device 112 is communicatively connected to the server 102 and the servers 103A to 103N via the network 110. In one implementation, the computing device 112, the server 102, and the servers 103A to 103N may communicate via one or more application programming interfaces (APIs) and / or according to other interfaces and / or technologies. In some other implementations, the computing device 112, the server 102, and the servers 103A to 103N (and their subcomponents) may communicate via one or more network calls (e.g., remote procedure calls) JavaScript Object Notation (JSON) via Hypertext Transfer Protocol (HTTP) requests, reports, etc.

[0029] The server 102, the servers 103A to 103N, and the computing device 112 may each include at least one network interface that enables communication with each other via the network 110. Examples of such network interfaces, wired or wireless, include an IEEE 802.11 wireless LAN (WLAN) wireless interface, a Worldwide Interoperability for Microwave Access (Wi-MAX) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth® interface, a cellular network ... TM interface, near field communication (NFC) interface, etc. Other examples of network interfaces are described elsewhere in this document.

[0030] The computing device 112 may include any device configured to generate database transactions and / or queries to one or more databases. The computing device 112 may include a desktop computer, a portable computer, a smart phone, a tablet, a wearable computing device, a hybrid and / or virtual reality device (e.g., Microsoft HoloLens) for generating database transactions and / or queries. TM ) or any other processing device. In some example implementations, the computing device 112 may include one or more computer programs, software, interfaces, etc. for accessing remote databases such as the control database 104 and databases 108A to 108N. It should be noted that although Figure 1 Such databases are illustrated as being located remotely from computing device 112, but implementations are not limited thereto. For example, computing device 112, server 102, and / or one or more of servers 103A to 103N may be co-located, may be implemented on a single computing device, or may be implemented on a Figure 1 on or distributed on one or more additional computing devices not explicitly shown in the figure. Figure 1A single computing device 112 is depicted, but it should be understood that implementations may include any number of computing devices (eg, client devices) coupled to the network 110, the server 102, and / or the servers 103A-103N. Figure 7 Example computing devices are described that may incorporate the functionality of server 102 , servers 103A- 103N, and / or computing device 112 .

[0031] According to some implementations, the computing device 112 may access one or more databases via the network 110. The computing device 112 may access the one or more databases in a variety of ways. In an example embodiment, the computing device 112 may include a transaction driver 114. The transaction driver 114 is configured to initiate a database transaction. For example, the transaction driver 114 may include client software, a machine, or a process to generate multiple transaction requests 116A to 116N and a driver report 118 corresponding to a single distributed transaction. Each of the transaction requests 116A to 116N may include a request to perform a portion of a distributed database transaction through various database participants. Each transaction request 116A to 116N may include, for example, a global identifier of the distributed transaction, a participant identifier identifying a database participant, and information related to the operation to be performed by the database participant. It should be noted and understood that although in Figure 1 104 and 108A to 108N, but the transaction driver 114 may be implemented in one or more of the servers 102 or 103A to 103N (or components thereof, such as the control database 104 and / or the databases 108A to 108N). In other words, the control database 104 and any one or more of the databases 108A to 108N may include a transaction driver configured to initiate a database transaction as described herein.

[0032] The driver report 118 includes a report identifying information associated with a database transaction initiated by the transaction driver 114. In some examples, the driver report 118 may include a collection or tuple of information related to a specific database transaction. The driver report 118 may include, but is not limited to, a global identifier of the distributed transaction, a transaction driver identifier, and an array or list including one or more participant identifiers that identify the participants of the database transaction as descendants of the transaction driver. Therefore, when the transaction driver 114 initiates a distributed transaction, the transaction driver 114 may send a transaction request 116A to 116N to each of the participants participating in the distributed transaction and send the driver report 118 to the control database 104. In some examples, the transaction driver 114 may send the transaction requests 116A to 116N to the participants and send the driver report 118 to the control database 104 in any order or asynchronously.

[0033] like Figure 1 As shown in , server 102 includes control database 104, and servers 103A to 103N may include databases 108A to 108N. Control database 104 includes transaction coordination system 106, which is configured to control and / or manage distributed database transactions on control database 104 and one or more of databases 108A to 108N. Server 102 or any one or more of servers 103A to 103N may include one or more server devices and / or other computing devices (including, for example, cloud-based computing platforms) that are co-located or remotely located.

[0034] The server 102 and each of the servers 103A to 103N (including the databases 108A to 108N) may also be communicatively coupled to a storage device or other repository (locally or remotely located to the server 102 or any of the servers 103A to 103N). Such storage devices may be configured to store data or other information maintained, managed, and / or accessed by the control database 104 and / or the databases 108A to 108N. In implementations, the storage devices may be configured to store information for hundreds, thousands, millions, and even greater numbers of users, event records, transactions, and the like. The control database 104 and the databases 108A to 108N may include any suitable data structure for storing information and are not limited to any particular implementation or format.

[0035] like Figure 1, although the control database 104 may be implemented in the server 102 and the databases 108A to 108N may be implemented in the servers 103A to 103N, it should be understood that any one or more of the control database 104 and the databases 108A to 108N may be implemented in Figure 1 108N. In some examples, the server 102 (or a distributed collection of servers) may be configured to implement the control database 104 and one or more of the databases 108A to 108N. In addition, the control database 104 and any one or more of the databases 108A to 108N may be remotely located so that access to each of the databases may be performed via the network 110. The control database 104 and any one or more of the databases 108A to 108N may include any type of physical storage device, including but not limited to one or more local storage devices and / or one or more cloud-based storage devices, such as hard drives, solid-state drives, random access memory (RAM) devices, and the like.

[0036] In some example embodiments, the control database 104 and the databases 108A to 108N may be implemented on one or more engines of a structured query language (SQL) server, such as the Hekaton engine. For example, the control database 104 and the databases 108A to 108N may include one or more in-memory transactional databases that other applications (such as the transaction driver 114) may access. The control database 104 and the databases 108A to 108N may each include a transactional log for identifying or recording transactions executed on the database in a serial manner.

[0037] Although not in Figure 1 , but each of the control database 104 and databases 108A to 108N may also include one or more replica databases, respectively. For example, the control database 104 and databases 108A to 108N may include a master database and one or more replica databases, respectively, on which transactions may be executed, and to which the transactions are copied or stored. In the event of a failure of a particular master database, the replica database may automatically replace the position of the master database and be responsible for executing the techniques described herein, thereby achieving seamless failover of different branches for coordinating and executing distributed transactions. In an implementation, the master database and the replica databases do not need to be implemented on the same machine, but may be distributed on multiple machines, implemented in a cloud, etc.

[0038] As described above, database transactions may include transactions involving multiple databases. As an illustrative example, a namespace transaction (e.g., creating or deleting a file) may require multiple separate operations to be performed in multiple different databases (including databases that may be executed on different systems or machines) for file names, directories, permissions, etc. For example, if a transaction driver creates a file, a pointer to the location of the identification file (e.g., a specific machine or system where the file resides) may be generated subsequently. In this example, one or more systems may be implemented to manage file related information, including but not limited to the scope or (multiple) data portions of the file. For example, a database (or multiple databases) may be implemented to track the naming and location of files on various machines or systems (including but not limited to a scope management database and a namespace management database). In other words, therefore, when creating a file, a first transaction may be executed in a namespace management database, and a second transaction associated with file creation may also be executed in a scope management database. Although two transactions may occur independently of each other (e.g., not at exactly the same moment), such transactions may either all need to be successfully executed, or both transactions should not be executed. If each part of such a distributed transaction is not performed consistently among all of the database participants involved, database inconsistencies may result, such as the inability to locate file extent information that indicates the storage location (or locations) of data portions of a file on a data center.

[0039] As described in more detail below, the transaction coordination system 106 can be configured to manage distributed transactions in a manner that avoids inconsistencies between database participants. In particular, because different database participants may each include separate systems and transaction logs that require consistent actions, distributed transactions must be executed atomically by all involved participants. In other words, to ensure consistent results, each part of the distributed transaction attributed to the various database participants should occur in its entirety, or none of the parts should occur.

[0040] Illustrative transaction coordination can be performed as follows. Once the transaction driver 114 initiates a distributed transaction, the transaction driver 114 can send transaction requests 116A to 116N to each database participant participating in the distributed transaction. Each of the databases involved (e.g., databases 108A to 108N) can create a local transaction representing a corresponding portion of the distributed transaction and execute part of the transaction (e.g., using the Hekton engine or any other execution engine). After executing the corresponding portion of the distributed transaction, each database participant can persist or save the transaction to a serialized log of a storage device (such as a non-volatile memory device or other stable media device) to solidify the local transaction. However, each participant can mark the transaction in its corresponding transaction log along with an indication or mark that the transaction should remain pending until a confirmation of the transaction is received from the transaction coordination system 106. Once such a confirmation is received from the transaction coordination system 106, it can be recorded in the transaction log of each participant. In some examples, the indication or marker may include the presence of a global identifier representing the distributed transaction, and once stored in the log, the confirmation may include the same global identifier, thereby linking the pending transaction and the confirmation of the transaction in the transaction log.

[0041] As will be discussed in more detail below, the transaction coordination system 106 can use temporary or non-persistent tables or other data structures to track a particular transaction based on reports received from the transaction driver and the involved parties to determine whether the transaction was committed by all of the distributed transaction participants or should be aborted by all of the participants. After the transaction coordination system 106 determines the final result of the transaction, the result can be stored in a log (such as a persistent transaction table) local to the transaction coordination system 106. The transaction coordination system 106 can also send the result to each participant, and each involved database participant can save the result in its corresponding log, which indicates whether the distributed transaction was fully committed or aborted. Once this confirmation is serialized to the log, the transactional memory associated with the pending transaction in each database participant can be released.

[0042] It should be noted and understood that the implementations described herein are not limited to depicting a single transaction coordination system 106 implemented in the control database 104. Figure 1106. Multiple transaction coordination systems similar to transaction coordination system 106 may be implemented in control database 104, one or more of the other databases, or one or more cloud-based servers or computing devices, local computing devices, etc., or distributed in any number of databases or systems. For example, when transaction driver 114 generates driver report 118, driver report 118 may be assigned to a particular transaction coordination system among multiple coordination systems that may be responsible for coordination of the transaction.

[0043] The transaction coordination system 106 can operate in various ways to coordinate distributed transactions. For example, the transaction coordination system 106 can operate in various ways to coordinate distributed transactions. Figure 2 to perform the operation. Figure 2 A flowchart 200 of a method for coordinating distributed transactions involving multiple database participants according to an example embodiment is shown. For illustrative purposes, reference is made to Figure 3 Flowchart 200 and transaction coordination system 106 are described as follows. Figure 3 A block diagram of a coordination system 300 for coordinating distributed transactions according to an example embodiment is shown. The coordination system 300 is Figure 1 Example implementations of the control database 104 and databases 108A to 108N. Figure 3 As shown in FIG. 1 , system 300 includes control database 104 and databases 108A to 108N. Figure 3 As shown in FIG. 1 , the control database 104 includes a transaction coordination system 106. The transaction coordination system includes a distributed transaction interface 302, a transaction coordinator 304, and a persistent transaction table 312. Figure 3 , the distributed transaction interface 302 may include a driver report 118 received from the transaction driver 114 and a participant report 306A to 306N received from each database participating in a particular distributed transaction. The transaction coordinator 304 includes a result determiner 308 and a pending transaction table 310. The databases 108A to 108N each include a transaction log 314A to 314N, respectively. In addition, as described below, each of the databases 108A to 108N participating in a particular distributed transaction may include a transaction request 116A to 116N generated by the transaction driver, and generate a participant report 306A to 316N. The flowchart 200 and the system 300 will be described in more detail below.

[0044] Figure 2 Flowchart 200 of FIG. 1 begins at step 202. In step 202, a driver report is received from a transaction driver, the driver report including a global identifier, a transaction driver identifier, and a participant identifier identifying a descendant of the transaction driver. Figure 1and Figure 3 , the distributed transaction interface 302 can receive a driver report 118 from the transaction driver 114. In some examples, after initiating a distributed database transaction involving multiple databases, the transaction driver 114 can generate a driver report 118 and send it to the distributed transaction interface 302. The driver report 118 may include a global identifier that uniquely identifies the distributed transaction, a transaction driver identifier, and a list of participant identifiers, each participant identifier identifying a participant responsible for a portion of the distributed transaction as a descendant of the transaction driver. However, it should be noted that the implementation is not limited to receiving the driver report 118 before receiving any other report. On the contrary, as described later, the distributed transaction interface 302 can receive the driver report 118 and any one or more participant reports 306A to 306N in any order.

[0045] The global identifier of a distributed transaction may be any identifier (e.g., a sequence of alphanumeric characters) that uniquely identifies the distributed transaction. In some implementations, the global identifier may be generated by the transaction driver 114 (e.g., in a local process). In other implementations, the global identifier may be generated in whole or in part by the transaction coordination system 106. The global identifier may be generated in any manner, including, but not limited to, sequentially, randomly, using a global identifier library, etc. As discussed herein, the global identifier that identifies a particular database transaction may be included in each report or request so that each distributed transaction (and its portions) may be accurately tracked.

[0046] The transaction driver identifier may include an identifier associated with the reporting entity. For example, in the case where the reporting entity is the transaction driver 114, the transaction identifier included in the driver report 118 may include a "null" value or other predetermined value or identifier. Such a value (e.g., a null value) may indicate to the distributed transaction interface 302 that the received report is being received from the initiator of the distributed transaction so as to distinguish it from other received reports (e.g., participant reports). For example, as described in more detail below, the distributed transaction interface 302 may receive a participant identifier in the same field of the received report, which may indicate that the sending entity is one of several database participants (as opposed to the transaction driver). In this way, regardless of the order in which the sending entity and the received report are sent, the database transaction interface 302 may be configured to receive and parse each report in a similar manner. As will be described in more detail below, upon receiving each report, the transaction coordinator 304 may update the pending transaction table 310 based on the information contained in each report to track the entities participating in a particular distributed transaction.

[0047] The driver report 118 may also include multiple participant identifiers. The participant identifier may identify each database participant participating in the transaction identified by the transaction driver 114 for a particular distributed transaction. In an example embodiment, each such participant may be responsible for conducting or executing a specific portion of the distributed transaction, as identified by the transaction driver. In other words, the driver report 118 may identify multiple participants that are descendants of the transaction driver 114 for a given transaction by corresponding participant identifiers. The participant identifier may similarly include a unique global identifier and may be generated in any manner (including, but not limited to, a similar manner as described above with respect to the generation of a global identifier that identifies a transaction). For example, the transaction driver 114 may generate a participant identifier that locally identifies a participant of a transaction in conjunction with the transaction coordination system 106 or in any other manner.

[0048] After initiating a distributed transaction, the transaction driver 114 can also be configured to send transaction requests 116A to 116N to the corresponding database participants identified by the transaction driver as participating in the database transaction. In an implementation, each such transaction request can include the same global identifier. The transaction request 116A to 116N can also identify a participant identifier for each of the database participants involved, and the participant identifier identifies each participant and one or more data operations to be performed in conjunction with the distributed transaction. Each database participant can perform the corresponding part of its distributed transaction after receiving the transaction request 116A to 116N and save the transaction to its transaction log (a transaction log in the transaction log 314A to 314N). In addition to other things, each distributed transaction saved to the transaction log can also include a global identifier of the distributed transaction. In this way, the database can easily determine which transactions are distributed transactions involving other database participants, and can easily determine which transactions are local (i.e., transactions without a global identifier and not involving other participants).

[0049] As an illustrative example, after initiating a transaction involving multiple database participants, the transaction driver 114 driver can be configured to send a driver report 118 to a distributed transaction interface 302, which includes a global identifier of the transaction, a transaction driver identifier, and a participant identifier of the participant responsible for the portion of the distributed transaction. In parallel, the transaction driver 114 can send transaction requests 116A to 116N to the various participants responsible for the portion of the distributed transaction. As used herein, the parallel sending of the driver report 118 and the transaction request 116A to 116N is not intended to be limited to any specific order of sending. On the contrary, the transaction driver 114 can send any one or more transaction requests in the transaction request 116A to 116N to the corresponding database participant before, at the same time, or after the driver report 118 is sent to the distributed transaction interface 302.

[0050] In step 204, it is determined whether a participant report has been received from each of the plurality of database participants. In some implementations, each participant report may include a global identifier identifying the transaction, a participant identifier of the participant, an identification of any descendant participant identifiers identifying descendants of the participant (e.g., in an array or list), and a status of the participant's portion of the distributed transaction. For example, referring to Figure 3 , each database participant participating in the distributed transaction can send its corresponding participant report among the participant reports 306A to 306N to the distributed transaction interface 302.

[0051] Each participant report may include an information tuple similar to the driver report 118. In some examples, the participant report may include the same or similar structure as the driver report 118. For example, similar to the driver report 118, the participant report may be sent to the distributed transaction interface 302 using a suitable network call, API, etc. In other words, the participant reports from the databases 108A to 108N may contain the same global identifier generated by the transaction driver 114 to identify the specific distributed transaction, the identifier of the reporting participant, the identifier associated with any descendant participants that are descendants of the reporting participant, and the results or status of the portion of the distributed transaction of the reporting participant. In an example, the identifier of the reporting participant may include a unique participant identifier generated by the transaction driver 114.

[0052] In some instances, a database participant identified by transaction driver 114 as responsible for a portion of a distributed transaction may determine that one or more additional database participants are needed to perform additional operations with respect to the same distributed transaction. Thus, any one or more of databases 108A through 108N participating in a particular distributed transaction (e.g., a parent participant) may identify one or more descendant participant databases (e.g., a parent participant) by generating a transaction request for each descendant participant in a manner similar to that described above with respect to transaction driver 114 and identifying the descendant participant identifier(s) generated by the parent participant. Figure 3 ). In addition, the parent participant may identify the identifiers of such descendant participants added to the transaction in its participant report to the transaction interface 302. In this way, the distributed transaction interface 302 may be aware of each participant participating in a particular transaction even if the particular participant is not directly identified by the transaction driver 114.

[0053] The participant reports 306A to 306N may also include the status of the portion of the distributed transaction for each reporting participant. For example, if a participant successfully conducts or executes the corresponding portion of its distributed transaction, the participant may record the transaction in the participant's transaction log and indicate in its corresponding participant report that the participant has committed the transaction. However, because the serialized transaction in the log includes a global identifier that identifies it as a distributed transaction, the transaction will remain pending or "in progress" until a confirmation is received from the transaction coordinator 304 later (described in more detail below). In other words, each distributed transaction recorded in the participant's transaction log may remain in a pending state and will be uncommitted in memory until a confirmation is received from the transaction coordinator 304. Up to the time the confirmation is received, the pending transaction may be visible to other operations, and other transactions may depend on the pending transaction, but these other transactions remain in a pending state until the confirmation received from the transaction coordinator 304 is serialized into the participant's transaction log.

[0054] However, in some instances, a distributed transaction may need to be aborted. For example, a party may not have successfully executed part of a particular transaction with respect to its database. In such an example, a party may identify in its party report that the party has aborted the transaction. In other examples, despite participating in a transaction, not all parties in a given distributed transaction may send a party report to the distributed transaction interface 302. For example, if a particular party does not receive a transaction request from the transaction driver 114 (e.g., due to a connection or network error or any other communication error), the party may not execute part of its distributed transaction. In such a scenario, because the party is completely unaware of the transaction, the party may not send a party report to the distributed transaction interface 302 to confirm the transaction.

[0055] Thus, the distributed transaction interface 302 can determine whether a participant report has been received from each participant participating in a particular distributed transaction, the participant report indicating, among other transactions, whether the participant has confirmed the transaction. As will be described in more detail below, if all of the involved participants confirm their respective parts of the same transaction, then the transaction coordination system 106 can confirm the transaction for all of the participants.

[0056] In step 206, the global identifier, the plurality of party identifiers, any descendant party identifiers of each party, and the state of the portion of the distributed transaction for each of the parties that sent the party report are stored in a table. Figure 3 , the transaction coordinator 304 can store a global identifier associated with the distributed transaction, multiple participant identifiers (including participants identified by the transaction driver and participants identified by other database participants) in the pending transaction table 310, and store the status of the portion of the distributed transaction for each participant that sent a report. In this way, the transaction coordinator 304 can track the status of a distributed transaction involving multiple participants.

[0057] According to some implementations, the pending transaction table 310 may include a temporary or non-persistent table or other data structure suitable for tracking the progress and entities participating in a particular distributed transaction. The pending transaction table 310 may be configured to build a hierarchical structure for a given transaction on-the-fly as the transaction coordinator 304 receives reports from various entities participating in the transaction. For example, if the pending transaction table 310 does not include such a structure for a given transaction (i.e., the global identifier is not found in the table), then the first report received with the global identifier may trigger the construction of an in-memory structure representing the transaction. In one example, the transaction coordinator 304 may receive the driver report 118 before receiving any of the participant reports 306A to 306N. In this example, the pending transaction table 310 may initiate the creation of an in-memory structure for the transaction (e.g., one or more entries in the pending transaction table) and identify each of the database participants identified in the driver report 118. If one or more participant reports 306A to 306N are subsequently received, the information corresponding to the global identifier in the table may be updated. For example, if the party identifier corresponding to the reporting party already exists in the table, then the table may be updated to indicate that the party has confirmed the transaction. In addition, the reporting party in such a scenario may identify one or more additional descendant parties that may not exist in the table. For each such new descendant party, the corresponding descendant party identifier may be added to the pending transaction table 310 (e.g., at the end of the linked list) based on the same global transaction identifier.

[0058] However, it should be noted that in some other illustrative examples, one or more of the participant reports 306A to 306N may be received by the distributed transaction interface 302 before the driver report 118 is received. In such examples, the transaction coordinator 304 may generate a structure corresponding to a transaction in the pending transaction table 310 in a similar manner by creating an entry for the global transaction identifier and adding the reporting participant identifier, any descendant participant identifiers, and the state of the portion of the transaction of the reporting participant. If other reports (e.g., the driver report 118 and / or one or more other participant reports 306A to 306N) are subsequently received, the transaction coordinator 304 may update the pending transaction table 310 with the received information. Thus, regardless of the order in which the reports are received, this process may be performed iteratively for each report received in an iterative manner, thereby enabling the transaction coordinator 304 to generate and update the pending transaction table 310 on the fly to create a complex tree or hierarchical structure of distributed transactions.

[0059] In some example embodiments, the pending transaction table 310 may include a hash map, a hash table, or other in-memory structure for storing a linked list of participants of the pending transaction. For example, when the transaction coordinator 304 obtains the global identifier of the distributed transaction from the transaction driver or any of the participants, a hash value may be calculated. Based on the hash value, the corresponding bucket of the hash map may be selected for storing information associated with the same global identifier. In another implementation, the hash map may include a lock-free hash map in the memory, such as a lock-free hash map stored on one or more volatile storage devices, random access memory (RAM) devices, etc. For example, in a lock-free hash map, an update to the pending transaction table 310 may enable multiple different processing threads to perform the same operation in the memory at the same time without preventing other operations from occurring. As an example, the operations performed by the control database 104 (including but not limited to updating the pending transaction table 310) may include one or more Interlocked.CompareExchange (ICX) operations as known to those skilled in the art, which may enable the operation to be performed (and retried if necessary) by multiple processing threads (e.g., in a multi-threaded system) in an atomic manner. Therefore, pending transaction table 310 may be updated in an efficient, lock-free, and iterative manner.

[0060] In step 208, the structure of the distributed transaction is determined using the table. For example, refer to Figure 3 , the result determiner 308 can be configured to use the pending transaction table 310 to determine the result of the distributed transaction corresponding to the global identifier. As discussed above, the pending transaction table 310 can dynamically build a hierarchical structure of distributed transactions involving multiple database participants. For example, if each of the participants and / or descendant participants (whether identified by the transaction driver 114 or by any other database participant) sends a corresponding participant report to the distributed transaction interface 302, the participant report indicates that the reporting participant has submitted the transaction, and the pending transaction table 310 can store such indications. Based on these indications that all participants and descendant participants who participated in a particular transaction have submitted the transaction, the result determiner 308 can determine that the distributed transaction is in a fully committed state.

[0061] In some other examples, the result determiner 308 can determine that a particular distributed transaction is in progress or incomplete. For example, if a participant or descendant participant has been added to the pending transaction table 310 by an entity (e.g., the transaction driver 114), but the participant and / or descendant participant has not yet sent its participant report, then the result determiner 308 can determine that the transaction is incomplete due to one or more participant reports of the confirmation transaction that have not yet been received.

[0062] In another example, the result determiner 308 can determine that a specific distributed transaction should be suspended. For example, if any participant or future participant fails to make a commitment to the transaction (such as in the case of execution or other transaction errors that have occurred on the database), the participant or future participant can send a participant report, which indicates that the reporting participant has suspended the part of the transaction belonging to the participant. In this example, the pending transaction table 310 can store the indication of the suspended transaction by the reporting participant, and the result determiner 308 can determine that all participants participating in the same transaction should suspend the transaction. In some other examples, the result determiner 308 can be configured to determine that a specific participant or future participant has suspended a part of the transaction belonging to the specific participant or future participant based on failing to receive a report after a period of time (for example, when the participant does not send a report after a certain number of seconds, minutes, etc.). For example, if a specific participant fails to send a participant report that confirms the transaction after a predetermined period of time, the result determiner 308 can determine that the entire transaction should be suspended due to a participant in the participant failing to submit the transaction. In such an example, the result determiner may record the transaction as an aborted transaction in the persistent transaction table 312 and / or send a transaction result to one or more of the involved parties, indicating that the transaction should be aborted. Thus, in the manner described herein, the transaction coordinator 304 may be able to manage and track the progress of complex distributed transactions involving multiple parties and accurately determine whether a transaction is fully committed or should be aborted.

[0063] In another example embodiment, when determining the result of a transaction, the transaction coordinator 304 may be configured to store the result in a persistent transaction table 312. The persistent transaction table 312 may include one or more transaction tables, arrays, lists, or other data structures for storing the final determined result of a distributed transaction (committed or aborted). For example, the persistent transaction table 312 may include one or more permanent tables, such as a table stored or persisted to a non-volatile storage device or a memory device. In some other implementations, after storing such a result in the persistent transaction table 312, the transaction (e.g., all entries corresponding to the same global identifier) ​​may be cleared from the pending transaction table 310, so that the memory (volatile memory of the in-memory hash table) is freed and can therefore be used for other purposes or transactions. This means of solidifying completed transactions in a persistent transaction table is advantageous because it does not require a series of complex transactions to be performed on a permanent storage device that typically has a slower read / write speed than an in-memory device. Instead, operations used to coordinate distributed transactions may be performed in a faster lock-free memory as described herein, and then saved to persistent table 312 using a single transaction once the final result is determined.

[0064] In step 210, the result of the distributed transaction is sent to at least one of the participants. Figure 3 , the distributed transaction interface 302 can be configured to send the result of the distributed transaction determined by the result determiner 308 to any one or more of the databases 108A to 108N. As previously discussed, the result of a particular distributed transaction can include various states, including that the transaction has been fully committed, has been aborted, or that the transaction is pending (i.e., waiting for one or more additional participants to report).

[0065] In some examples, the distributed transaction interface 302 can automatically and / or in response to a request by one of such participants or in response to any other event send the result to one or more (or all) of the databases 108A to 108N participating in the transaction. Similarly, the distributed transaction interface 302 can be configured to send the result of the distributed transaction to the transaction driver 114 automatically (e.g., after determining the final result) or in response to a driver request for a result.

[0066] It should be noted and understood that, although the result of a distributed transaction is described in the example as being sent to at least one of the participants of a particular distributed transaction, such sending (or multiple sending) of the result may not occur in some implementations. For example, the distributed transaction interface 302 may not send the result to any of the involved participants. As an illustrative example, all of the involved participants (databases 108A to 108N) may send a corresponding participant report indicating that a particular transaction is aborted and then crashes after sending the report. In this example, the result determiner 308 may determine that the result of the transaction will abort the transaction and record the result to the persistent transaction table 312. However, because each of the database participants in the database participants has crashed and the database participants may no longer have any record of the aborted transaction, the database participants may no longer be aware of the aborted transaction. Therefore, the participants may not send subsequent participant reports related to the transaction to the coordinator, and the coordinator does not need to send (or in some instances, resend) the result of the transaction to the involved participants. However, if a participant report is subsequently received for the transaction, the distributed transaction interface 302 may determine, based on the information in the persistent transaction table 312, that the transaction outcome has been determined, and send the outcome to the reporting participant at that time.

[0067] After receiving the result of the distributed transaction, the parties involved in the distributed transaction can serialize the transaction log 314A to 314N with the final result. The transaction log 314A to 314N can perform updates in various ways. For example, the transaction log 314A to 314M may include a serialized entry in the transaction log that identifies the completed distributed transaction by its global identifier and the final result of the transaction (e.g., commit or abort). Therefore, the pending distributed transaction can be linked to the transaction result, so that the transaction can be made clear in the log of each party.

[0068] In this manner, each of the transaction logs 314A to 314N can become self-sufficient with respect to a particular distributed transaction involving multiple other independent database participants after receiving the final result of the particular transaction. In other words, any one of the databases 108A to 108N can determine the status of a distributed transaction for which a final result has been reported through the transaction coordination system 106 based solely on its local transaction log. Therefore, for such distributed transactions for which a final result has been reported to the involved participants, the database participants do not need to interact with the control database 104 or any other entity to confirm the transaction results.

[0069] According to some embodiments described herein, therefore, the distributed transactions involving multiple databases can be accurately and consistently coordinated. A non-restrictive illustrative process for coordinating distributed transactions is described as follows. As previously discussed, distributed transactions can be initiated by a transaction driver and are assigned a global identifier (DI in this example). The transaction driver can send a driver report to a control database, and also send a transaction request to each database in the multiple databases participating in the transaction. As described above, the database participants can send the participant report to the control database after confirming their respective parts of the distributed transaction. The control database (e.g., control database 104) responsible for coordinating the transaction can receive any participant report in the driver report or the participant report in any order.

[0070] After receiving a report from any of the entities participating in the transaction, the control database 104 may first determine whether the global identifier in the report exists in a durable transaction table (e.g., durable transaction table 312). If the global identifier exists in the durable table, then the result determiner 308 has previously determined the final result of the transaction corresponding to the global identifier (D1), and the transaction coordinator 304 may be caused to send the result back to the reporting participant (e.g., identifying whether the transaction has been committed or aborted based on information stored in the durable table).

[0071] If the persistent table does not contain a global identifier, then the final result of the distributed transaction has not yet been reached, and the transaction can be determined to be "in progress". In this scenario, the transaction coordinator 304 can determine whether the pending transaction table 310 includes an existing entry corresponding to the global identifier identified in the received report. If the pending transaction table does not include an existing entry corresponding to the global identifier identified in the received report, the transaction coordinator 304 can create a new entry identifying the global identifier (DI) and insert the information received in the driver report or participant as described above. In some examples, the information in the pending transaction table 310 for a particular global identifier may include a result state that is first initialized with an "in progress" state after generation, which can be later updated to "committed" or "aborted". The "in progress" state can indicate that the transaction coordinator is waiting to receive one or more reports (e.g., a participant report, a descendant participant report, or a driver report) before confirming the entire transaction.

[0072] If the global identifier exists in the pending transaction table 310, the transaction coordinator 304 can update the information corresponding to the global identifier using the information in the received report. Thus, the pending transaction table 310 can generate a linked list of participants participating in a particular distributed transaction, which is continuously updated as additional reports are received. In this way, the transaction coordinator 304 can dynamically create a hierarchical structure of distributed transactions without having to model any structure of the transaction (including the identification of its participants) or make any structure of the transaction known before initiating the transaction.

[0073] According to some implementations, each participant identified in the linked list of pending transaction table 310 may include three states: added by parent, added by descendant, or both confirmed. When a reporting entity sends a report containing one or more participant identifiers (a reporting participant identifier and / or any identifier of a descendant participant), a state associated with any of the identified participants may be added or updated in pending transaction table 310. If a received report identifies a particular participant for the first time (i.e., the participant identifier is not already in pending transaction table 310), then the new participant is added to pending transaction table 310 as "added by parent" or "added by descendant", depending on whether the new participant is added to pending transaction table 310 by a parent entity (such as transaction driver 114 or a parent participant) or whether the new participant is added to the table by the reporting participant itself.

[0074] Once added to the pending transaction table 310, the status of "added by parent" and "added by descendant" can be updated to a "both confirmed" status based on the receipt of subsequent reports. For example, if the driver report 118 is the first entity to identify a database participant (P1 in this example) to control the database 104, then the participant P1 can be added to the pending transaction table 310 with a status of "added by parent". If the participant P1 subsequently sends a participant report confirming its portion of the transaction, then the pending transaction table 310 can update the status of the participant P1 to "both confirmed" because both the parent (transaction driver 114 in this example) and the descendant (participant P1) have confirmed the transaction. In a similar manner, the status can be changed from "added by descendant" to "both confirmed", where the controlling database 104 first receives a participant report from the participant P1 confirming the portion of the transaction before receiving a report from the parent entity (e.g., transaction driver). In some examples, outcome determiner 308 may determine that a transaction is fully committed only if all parties identified in pending transaction table 310 for a given transaction include a "both confirmed" status.

[0075] However, it should be noted that the parent and descendant participants are not limited to the described examples. In particular, the parent participant may include any parent entity that identifies a participant database for a transaction, and the descendant participant may include any descendant entity that has been added to a distributed transaction by another entity.

[0076] In some examples, a participant identifier identified in a received report (e.g., a driver report or a participant report) may be added to the pending transaction table 310 before other actions are taken, including determining the outcome of the transaction. For example, because actions taken by the control database 104 (including any modifications to the pending transaction table 310) may be performed based on one or more ICX operations, a parallel thread may produce a premature outcome determined for a distributed action while the pending transaction table 310 is being updated. As an example, the control database 104 may first receive a driver report that identifies a particular participant P1 (among other participants), and then receive a participant report from participant P1 that confirms the corresponding portion of its transaction but also adds a new participant (e.g., participant P3) to the transaction. If the pending transaction table 310 is updated to change participant P1 to a "both confirmed" state before participant P3 is added to the table, the outcome determiner 308 may prematurely determine that the distributed transaction has reached a final state if all other participants in the table are also in a "both confirmed" state. To avoid such premature conclusions, transaction coordinator 304 may be configured to first add descendant participant identifiers to pending transaction table 310. Thus, outcome determiner 308 may know that it should wait for reports from newly identified descendant participants before reaching a final outcome with respect to the entire transaction.

[0077] In some example embodiments, upon first receiving the driver report 118 through the control database 104, the transaction coordinator 304 may add the transaction driver identifier (in this example, "null") in the pending transaction table 310 in an "add by parent" manner. In other words, the transaction driver itself may be added as a participant with a pending state in the linked list of the pending transaction table 310. After adding the transaction driver, the transaction coordinator 304 may identify each of the participants identified in the driver report as "add by parent" in the linked list of the pending transaction table 310. After this operation, the transaction coordinator 304 may update the transaction driver identifier ("null") in the linked list to "add by descendant", thereby placing the transaction driver in a "both confirmed" state. By enabling the transaction driver to remain in a pending state in this manner, the transaction coordinator 304 may prevent the outcome determiner 308 from prematurely reaching a final conclusion about the distributed transaction before adding one or more participants to the pending transaction table 310 in a similar manner.

[0078] The result determiner 308 can be configured to traverse the linked list of participants in the pending transaction table 310 to determine whether all of the identified participants are in the "both confirmed" state. If all of the identified participants of a particular transaction are in this state (i.e., the transaction is confirmed by the parent entity and the descendant entity), then the result determiner 308 can determine that the transaction is in a fully committed state. In other words, since no more participants are added to the pending transaction table 310 of the transaction, the list of the particular transaction becomes immutable at this time. As described above, the result determiner 308 can also be configured to change the transaction state from "in progress" to "committed", send the result to one or more participants participating in the transaction, and store the transaction in the persistent transaction table 312 after determining the final result. However, it should be noted that if a particular reporting entity sends a report indicating that the state of a portion of a participant's transaction is aborted, then the "result" state of the distributed transaction can be updated from the "in progress" state to the "aborted" state, which can result in the abortion of the entire distributed transaction.

[0079] FIG. 4A to FIG. 4B A block diagram depicting illustrative coordination of distributed transactions according to the above process according to an example embodiment is shown. FIG. 4A to FIG. 4B Each of the figures shows a system 400 for coordinating distributed transactions, wherein the system 400 includes a control database 402, a database 410, a database 420, a database 430, and a transaction driver 114. FIG. 4A to FIG. 4B In the illustrative implementation of FIG. 4 , control database 402 may be an example of control database 104. Database 410, database 420, and database 430 may be examples of databases 108A-108N that participate in a particular distributed transaction.

[0080] exist FIG. 4A to FIG. 4B In the example of , a distributed transaction can be initiated by a transaction driver 114 and assigned a unique global identifier D1. The transaction driver 114 can send a driver report to the control database 402. The transaction driver 114 can also send a transaction request 416 to the database 410 and a transaction request 426 to the database 420. In the example, the transaction request 416 and the transaction request 426 are examples of transaction requests 116A to 116N. The transaction driver 114 can send a driver report 118 to the control database 402 and send transaction requests 416, 426 to the databases 410, 420 in any particular order. For example, the driver report 118 can be sent before, after, between, or simultaneously with any of the transaction requests 416, 426.

[0081] like Figure 4AAs shown in , database 410 can identify database 430 as a new descendant participant of the same transaction (D1) by sending a transaction request to database 430. FIG. 4A to FIG. 4B , transaction driver 114 may be a parent entity of database 410 and database 420, while database 410 and database 420 are descendants of transaction driver 114. Similarly, database 410 may be a parent entity of database 430 by virtue of adding database 430 to the same transaction. As described in more detail below, any of databases 410, 420, and 430 may send a respective participant report to control database 402 after confirming its respective portion of the distributed transaction. It should be understood that these examples are not intended to be limiting and may include any number of parent entities and / or descendant entities and any combination of parent entities and / or descendant entities for any distributed transaction.

[0082] exist FIG. 4A to FIG. 4B In the illustrative example of , the driver report 118 includes a global identifier (D1) of the distributed transaction, an identifier of the transaction driver (which may be "null" in this example), and identifiers of the participants of the distributed transaction that are descendants of the transaction driver 114 (in this example, the descendant list includes P1 of the identification database 410 and P2 of the identification database 420). The global identifier (D1) and the participant identifiers (P1, P2) of the driver report 118 can be generated by the transaction driver 114. In some examples, the driver report 118 can include the same format as the participant report described herein so that the same network calls and / or APIs can be used to communicate with the control database 402. In such examples, similar to the status indicators included in the participant reports previously described, the driver report 118 can also include a commit or abort status indicating whether the transaction driver 114 has committed the distributed transaction or has aborted the distributed transaction.

[0083] exist Figure 4A In the illustration shown in , database 410 may receive a transaction request 416 involving it, the transaction request including a global identifier (D1) of a distributed transaction, a party identifier (P1) of database 410, and a database operation (e.g., payload data, instructions, etc.) to be performed by database 410. Similarly, database 420 may receive a transaction request 426 involving it, the transaction request including a global identifier (D1) of a distributed transaction, a party identifier (P2) of database 420, and a database operation to be performed by database 420.

[0084] As described above, database 410 may determine that a separate database participant (i.e., database 430) needs to perform operations in conjunction with the same distributed transaction. Therefore, in this illustrative example, database 410 may identify database 430 as a descendant of database 410 and assign a descendant participant identifier (P3 in this example) to the descendant database. Database 410 may then send a transaction request to database 430 that includes the same global identifier (D1) of the distributed transaction, a descendant participant identifier (P3) identifying database 430, and the operations to be performed by database 430 in conjunction with the transaction. In some other implementations, transaction driver 114 or another entity may generate the descendant participant identifier.

[0085] After confirming the portion of the transaction contained in the transaction request 416 and initiating the transaction request to the database 430 (participant P3), the database 410 can store the indication as a pending transaction 414 in the transaction log 412. The transaction log 412 is an example of a transaction log in the transaction logs 314A to 314N, and can include a serialized transaction log configured to store any number of transactions on the database 410, including but not limited to any number of distributed transactions or local transactions (i.e., non-distributed transactions that do not involve other database participants). In the example, the pending transaction 414 can identify the transaction by a global identifier (D1), which indicates that the transaction is a distributed transaction involving other database participants. Therefore, the pending transaction 414 remains in a pending state until a confirmation of the transaction appears later in the transaction log. It should also be noted that in addition to the global identifier, additional information related to the transaction can be serialized to the transaction log 412 associated with the pending transaction 414, including but not limited to the participant identifier (P1 in this example), any descendant participant identifiers (P3 in this example), and / or the status of the participant's portion of the transaction (e.g., committed or aborted status). In this way, the pending transaction 414 can include information to be included in subsequent participant reports that are resent to the control database 402, such as where the report was not received or the control database 402 crashed.

[0086] After storing the distributed transaction as a pending transaction 414, the database 410 may send a participant report as described above to the control database 402 via a network call or any other means. In this illustrative example, the participant report of the database 410 may identify the global identifier (D1) of the distributed transaction, the identifier of the reporting participant (i.e., the participant identifier of the database 410, or P1 in this example), the identifier of any descendant participant (i.e., the descendant participant identifier of the database 430, or P3 in this example), and the status of the portion of the transaction of the database 410 (e.g., commit or abort status). Therefore, even if the driver report 114 does not identify the descendant participant as a participant in the transaction, the transaction coordinator 304 may still learn about any descendant participants identified by other database participants by receiving the participant report. Therefore, because the transaction coordinator 304 learns about each participant of the distributed transaction in a dynamic manner, the transaction coordinator 304 can determine from which entity it must wait for a response before the final transaction result can be determined.

[0087] Database 430 can operate in a similar manner. For example, database 430 can receive a transaction request from database 410 and store the transaction as pending transaction 434 in transaction log 432. In this example, pending transaction 432 can identify a distributed transaction in a similar manner by the same global identifier (D1). After storing the transaction in transaction log 432, database 430 can use a network call as previously described to control database 402 to send a descendant participant report. The descendant participant report may include a format similar to the participant report sent by database 410. In this example, the descendant participant report may include the same global identifier (D1), an identifier of the reporting participant (i.e., an identifier of database 430, or P3 in this example), an identifier of any additional descendant participant (none in this example), and a state of the portion of the transaction that belongs to database 430 (e.g., a commit or abort state).

[0088] As described above, database 420 may similarly receive transaction request 426 from transaction driver and store the transaction as pending transaction 424 in transaction log 422. After storing the transaction as pending transaction 424, database 420 may similarly send a participant report to transaction coordinator 304 using a network call or other technique. In this example, the participant report of database 420 may include a global identifier (D1), an identifier of the reporting participant (i.e., an identifier of database 420, or P2 in this example), any identifiers of descendant participants (none in this example), and the status of the portion of the transaction of database 420 (e.g., committed or aborted status).

[0089] It should be noted and understood that FIG. 4A to FIG. 4B The specific arrangement of is illustrative only, and may include any number of databases, participants, descendant participants, transaction drivers, and control databases. For example, although not shown here, any one or more of databases 410, 420, or 430 may include any number of additional descendant participants, not shown. As described above, each such additional descendant participant may be configured to store pending transactions identifying distributed transactions in a corresponding transaction log and send participant reports to control database 402.

[0090] As discussed herein, the transaction coordinator 304 may store information obtained in each participant report and the driver report 118 in the pending transaction table 310 as it is received. For example, if the transaction coordinator 304 first receives a participant report from one of the databases 410, 420, or 430, the received participant report may initiate the generation of one or more entries in the pending transaction table 310 corresponding to the global identifier (D1). Similarly, if the transaction coordinator 304 first receives a driver report 118, the received driver report may initiate the generation of an entry in the pending transaction table 310 corresponding to the global identifier. Each subsequently received report for the same global identifier may enable the transaction coordinator 304 to update the pending transaction table 310. In this manner, regardless of the order in which the reports are received, the transaction coordinator 304 may be configured to populate the pending transaction table 310 corresponding to a particular transaction.

[0091] Figure 4B Describes what happens once the result determiner 308 determines the final result of the distributed transaction. Figure 4A For example, after receiving a driver report and / or multiple participant reports for a particular distributed transaction (specified by the global identifier D1 in this example), the pending transaction table 310 may include multiple participant identifiers participating in the transaction and whether each participant has committed or aborted its corresponding part of the transaction.

[0092] As described above, if two separate reports corresponding to a participant are received through the distributed transaction interface 302, then the pending transaction table 310 can indicate that the particular participant has been fully committed. Specifically, the participant identifier can be initially added to the pending transaction table 310 when the particular participant is first identified to the transaction coordinator 304. For example, if the transaction driver 114 first identifies the participant, then the pending transaction table 310 can add the participant and store an indication that the participant is "added by a parent" (e.g., the parent is the transaction driver in this example). Conversely, if the participant itself responds with a participant report before receiving the driver report 118, then the pending transaction table 310 can add the participant to the table and store an indication that the participant is "added by a descendant" (e.g., the descendant is the participant because it is a descendant of the transaction driver). Once a participant is first added to the table in an "add by parent" or "add by descendant" manner, the transaction coordinator 304 can wait for an appropriate report from the other entity (e.g., if the participant reports first, then wait for a report from the driver, or if the driver reports first, then wait for a report from the participant).

[0093] In the above example, where two reports are received (i.e., a report by the parent adding the participant and a report from the participant itself), the pending transaction table 310 may be updated to store an indication that the participant is in a "both confirmed" state. If either the parent or the descendant fails to confirm or send an abort status, then the portion of the transaction for the particular participant may be aborted. In such examples, the pending transaction table 310 may be updated to indicate that the particular participant has aborted the transaction. By waiting for reports from both entities participating in the portion of the particular participant's transaction, the transaction coordinator can ensure that the portion of the distributed transaction is properly confirmed.

[0094] In the above example, if the pending transaction table 310 indicates a "both confirmed" state for all parties identified for a given transaction, then the outcome determiner 308 can determine that the entire transaction has a final confirmed state. In an example, such a final state can be a fully committed state, in which each parent entity and descendant entity identified in the pending transaction table 310 has committed to a corresponding portion of the transaction. In other examples, if any entity fails to commit to the transaction after a predetermined period of time or has aborted a portion of the transaction, then the outcome determiner 308 can determine that the transaction as a whole should be aborted by all entities.

[0095] Once the result determiner 308 determines the result of the transaction, the transaction coordinator 304 may send the result to one or more entities participating in the distributed transaction, including Figure 4B410, 420, 430 and / or transaction driver 114 shown in . The results of the transactions can be stored in transaction logs 412, 422, and 432 as transaction results 416, 426, and 436, respectively. In some implementations, transaction results 416, 426, and 436 may include the same global identifier as pending transactions 414, 424, and 434 and the final result of the distributed transaction (e.g., whether the transaction is committed or aborted by all involved parties), so that the transaction results can be linked to the pending transactions in the log. Therefore, when a pending transaction is linked to a transaction result in the transaction log, the transaction no longer remains in a pending state and can be fully committed (e.g., permanently in memory) or aborted (e.g., rolled back).

[0096] It should also be noted that in the above examples, the transaction coordinator 304 can be configured to receive multiple party reports or driver reports from the same entity without adversely affecting the coordination of the distributed transaction. For example, any one or more of the databases 410, 420, or 430 can be closed, frozen, lose network connection, crash, etc., which can cause the database to be restarted and / or the database to be temporarily continuously offline. In such scenarios, the restarted or offline database can have one or more pending distributed transactions identified in the transaction log of the database without the corresponding transaction results. In these examples, the restarted or offline database can search its transaction log to identify any such distributed transactions that are pending after recovery, and resend the party report to the transaction coordinator 304 in the same manner as described above (e.g., the party report indicates the global identifier, the reporting party identifier, any descendant party identifier, and the status of the transaction). After receiving the party report, the control database 402 can determine (e.g., by searching the persistent transaction table 312) whether the result has been previously determined. If the previous outcome has not been determined, the control database 402 can determine whether the information in the received report is already in the pending transaction table 310 based on previous transmissions of the same report, or can add the information to the table if it does not already exist. Thus, the transaction coordinator 304 can be configured to update the pending transaction table 310 in an iterative manner and seamlessly coordinate transactions involving participants that may have temporarily failed for any number of reasons.

[0097] Similarly, if the control database 402 causes the information contained in the pending transaction table 310 for a particular transaction to be restarted, temporarily offline, or otherwise lost, the transaction coordinator 304 can automatically rebuild and / or repopulate the pending transaction table 310 with the information of the transaction. For example, in the event that the control database 402 crashes and the pending transaction table 310 is lost due to a pending transaction, each of the entities participating in the transaction can resend its respective report to the transaction coordinator 304. Such retransmissions can occur automatically after a predetermined period of time, such as in the event that a participant or transaction driver has sent a report but has not received a response after a certain period of time (e.g., a timeout period). Thus, the transaction coordinator 304 can automatically repair the pending transaction table 310 and reconstruct information for complex distributed transactions that may have been lost due to a crash or the like.

[0098] In another other example embodiment, a participant may be configured to submit a transaction to its local transaction log in order to abort a particular distributed transaction. For example, a participant (e.g., one of databases 410, 420, or 430) may store an indication that a particular distributed transaction has been submitted as a pending transaction 414, 424, or 434, while also sending a participant report "distributed transaction that the transaction should be aborted" to interface 302. Thus, while a particular participant may be configured to locally verify or confirm its portion of a distributed transaction, control database 402 will receive a report indicating that the transaction should be aborted, thereby causing the global transaction as a whole to be aborted (and causing one or more transaction results to be consistent with such determinations generally sent as described herein). In some cases, a participant providing a portion of a participant's distributed transaction may also be configured to store additional information in transaction log 412, 422, or 432 as an indicator, marker, etc. indicating that the transaction is intended to be aborted and / or that a participant report has been sent to the transaction coordinator containing the aborted status of the transaction. In some other instances, a database participant may generate additional entries in its transaction log, such as a separate local transaction that is not part of a global transaction or an entry that is otherwise linked to a global transaction in the log (e.g., as a pair of transactions or entries where one entry is part of a global transaction and the other transaction is a local transaction that is not part of the global transaction).

[0099] In this way, information associated with a global transaction indicating that the transaction should be aborted can be solidified in the local transaction log, and thus remain persistent in the event that a participant undergoes recovery after a crash, restart, etc. Thus, after recovery, a participant can resend the same participant report to the transaction coordinator indicating that the transaction should be aborted, thereby aborting the distributed transaction for all involved participants. In this way, the transaction coordinator can reach a consistent result (e.g., an abort result) for a particular transaction even if a participant database has been restarted or crashed.

[0100] As described above, the result of a transaction may be sent to one or more entries participating in the distributed transaction. Figure 5 A flowchart 500 is shown of a method for processing a request for a result of a distributed transaction of a participant according to an example embodiment. In an implementation, the method of flowchart 500 may be implemented by transaction coordinator 304. Figure 3 and FIG. 4A to FIG. 4B Describes Figure 5 Based on the following flow chart 500 and Figure 3 System 300 and FIG. 4A to FIG. 4B Based on the discussion of system 400, other structural and operational implementations will be apparent to those skilled in the relevant art(s).

[0101] Flowchart 500 begins at step 502. In step 502, the result of the distributed transaction is sent to one of the participants in the transaction in response to receiving a request from the participant. Figure 3 and FIG. 4A to FIG. 4B , the result determiner 308 can determine that a particular distributed transaction including a global identifier and involving multiple database participants has reached a final result (e.g., commit or abort). The transaction coordinator 304 can send the result to any of the database participants participating in the transaction in response to receiving a request from the participant. In one example, the participant report sent by the participant to the control database 104 can itself be or alternatively include a request for the result of the transaction. In addition to the participant report, the request can also be sent to the control database 104 by any of the participants as an independent request. For example, the participant can send such a request after a predetermined time period, and the predetermined time period has passed after sending the participant report. As an example, the participant can generally send its participant report as described herein to confirm the distributed transaction, and automatically send a request for the final result of the transaction to the control database 104 after a timeout period. In some other examples, the participant can continuously send a request to the control database 104 to request the result of the distributed transaction at a predetermined time interval.

[0102] In some other examples, such as where a database participant has crashed, the participant can search its transaction log to identify each distributed transaction in a pending state (i.e., a distributed transaction in the log whose associated transaction results are not serialized to the log). For each such transaction, the participant can send a request for the final result of the transaction (or resend a participant report including the request). As previously discussed, since each participant's local transaction log includes the appropriate information included in the previously sent participant report (global identifier, participant identifier, descendant participant identifier, and the status of the portion of the transaction), retransmitting the participant report after a crash or other event can be performed with reduced workload. In response, the control database 104 can determine whether the transaction has reached a final state based on the information contained in the persistent transaction table 312 or the pending transaction table 310, and return the result of the transaction to the requesting participant. In some other scenarios, as described above, such as where the control database 104 itself has crashed, resulting in loss of information in the pending transaction table 310, the request (which may include a participant report for a participant) may automatically trigger a reconstruction of the transactions in the pending transaction table 310.

[0103] It should be noted that the transaction coordinator 134 is not limited to sending the final result of the transaction to the participants. Instead, the transaction coordinator 304 can be configured to send the current status of the distributed transaction (e.g., "in progress" status, completion percentage, etc.) based on the information contained in the pending transaction table 310. In another implementation, the transaction coordinator 304 can be configured to identify one or more participants for which the control database 104 is still waiting for the participant report. In some other implementations, the transaction coordinator 304 can also be configured to send the result or status of a particular transaction to the transaction driver 114 in response to a request executed by the driver.

[0104] In an implementation, the transaction coordinator may receive reports from various entities participating in the distributed transaction, including driver reports, participant reports, and descendant participant reports. Figure 6 A flowchart 600 is shown of a method for processing a descendant participant report received from a descendant participant according to an example embodiment. In an implementation, the method of flowchart 600 may be implemented by transaction coordinator 304. Figure 3 and FIG. 4A to FIG. 4B Describes Figure 6 Based on the following description of the flowchart 500 and Figure 3 System 300 and FIG. 4A to FIG. 4B Based on the discussion of system 400, other structural and operational implementations will be apparent to those skilled in the relevant art(s).

[0105] Flowchart 600 begins at step 602. In step 602, a descendant participant report is received from at least one descendant of a participant in a distributed transaction. Figure 3 , the distributed transaction interface 302 may be configured to receive a descendant participant report from at least one descendant of a database participant. In an example, a descendant participant may include any participant identified or added to a particular distributed transaction by another database participant. For example, referring to Figure 4A , where database 410 (having participant identifier P1 in the above example) adds database 430 (having participant identifier P3) to a distributed transaction, database 430 may be a descendant participant of database 410. In such an example, after executing its respective portion of the distributed transaction identified by database 410, database 430 (P3) may be configured to store the pending transaction as pending transaction 434 in transaction log 432. Database 430 may also be configured to send a descendant participant report to distributed transaction interface 302, the descendant participant report including a format similar or identical to a participant report sent by database 420 and / or database 420. For example, the descendant participant report of database 430 may include the global identifier (D1) of the distributed transaction, the descendant participant identifier (P3), an identification or list of any additional descendant participant identifiers (none in this example), and the status (committed or aborted) of the descendant participant's portion of the distributed transaction.

[0106] In step 602, the state of the portion of the distributed transaction of the descendant participants is stored in a table. FIG. 4A to FIG. 4B , the transaction coordinator 304 may cause the pending transaction table 310 to store the status of the portion of the transaction. In one example, the status may indicate whether the descendant participant is in an "added by descendant" state, such as when the descendant participant identifier is not already in the pending transaction table 310. In another example, if the pending transaction table 310 already includes the descendant participant identifier (P3) along with the "added by parent" state, then the pending transaction table 310 may be updated to change the state to a "both confirmed" state upon receiving the descendant participant report. In other examples, the status may include an indication or flag identifying whether the descendant participant has committed to the distributed transaction or has aborted the distributed transaction.

[0107] However, it should be understood that, upon receiving a descendant participant report, the distributed transaction interface 302 may cause the transaction coordinator 304 to take any other actions described herein, including, but not limited to, returning the final result or status of the distributed transaction to the descendant participant, updating the pending transaction table 310 based on information in the descendant participant report (e.g., identifying a new descendant), and / or initiating construction of the transaction if a transaction does not already exist in the pending transaction table 310 (e.g., if the descendant participant is the first entity to send a report corresponding to the global identifier).

[0108] III. Example Mobile and Fixed Device Embodiments

[0109] Server 102, servers 103A to 103N, computing device 112, control database 104, transaction coordination system 106, databases 108A to 108N, transaction driver 114, distributed transaction interface 302, transaction coordinator 304, persistent transaction table 312, control database 402, database 410, database 420, database 430, flowchart 200, flowchart 500 and / or flowchart 600 can be implemented using hardware or hardware combined with software and / or firmware, such as implemented as computer program code / instructions stored in a physical / hardware-based computer-readable storage medium and configured to be executed in one or more processors or implemented as a hardware logic / electrical circuit system (for example, an electrical circuit composed of transistors, logic gates, operational amplifiers, one or more application-specific integrated circuits (ASICs), one or more field-programmable gate arrays (FPGAs)). For example, one or more of server 102, servers 103A to 103N, computing device 112, control database 104, transaction coordination system 106, databases 108A to 108N, transaction driver 114, distributed transaction interface 302, transaction coordinator 304, persistent transaction table 312, control database 402, database 410, database 420, database 430, flowchart 200, flowchart 500, and / or flowchart 600 may be implemented separately or together in a SoC. A SoC may include an integrated circuit chip that includes one or more of a processor (e.g., a central processing unit (CPU), a microcontroller, a microprocessor, a digital signal processor (DSP), etc.), a memory, one or more communication interfaces, and / or other circuits, and may optionally execute received program code and / or include embedded firmware to perform functions.

[0110] Figure 7An exemplary implementation of a computing device 700 in which an embodiment may be implemented is depicted. For example, any of server 102, servers 103A to 103N, computing device 112, control database 104, transaction coordination system 106, databases 108A to 108N, transaction driver 114, distributed transaction interface 302, transaction coordinator 304, persistent transaction table 312, control database 402, database 410, database 420, or database 430 may be implemented in one or more computing devices similar to computing device 700 in a fixed or mobile computer embodiment (including one or more features and / or alternative features of computing device 700). The description of computing device 700 provided herein is provided for illustrative purposes and is not intended to be limiting. As will be known to those skilled in the relevant art(s), embodiments may be implemented in other types of computer systems.

[0111] like Figure 7 As shown in FIG. 7 , computing device 700 includes one or more processors referred to as processor circuits 702, system memory 704, and bus 706 coupling various system components including system memory 704 to processor circuits 702. Processor circuit 702 is an electrical and / or optical circuit implemented in one or more physical hardware electrical circuit device elements and / or integrated circuit devices (semiconductor material chips or dies) as a central processing unit (CPU), microcontroller, microprocessor, and / or other physical hardware processor circuit. Processor circuit 702 can execute program codes stored in computer-readable media, such as program codes of operating system 730, application programs 732, other programs 734, etc. Bus 706 represents one or more of any of several types of bus structures, including memory buses or memory controllers, peripheral buses, accelerated graphics ports, and processor or local buses using any of various bus architectures. System memory 704 includes read-only memory (ROM) 708 and random access memory (RAM) 710. Basic input / output system 712 (BIOS) is stored in ROM 708.

[0112] The computing device 700 also has one or more of the following drives: a hard disk drive 714 for reading from and writing to a hard disk, a disk drive 716 for reading from or writing to a removable disk 718, and an optical drive 720 for reading from or writing to a removable optical disk 722, such as a CD ROM, DVDROM, or other optical media. The hard disk drive 714, the disk drive 716, and the optical drive 720 are connected to the bus 706 via a hard disk drive interface 724, a disk drive interface 726, and an optical drive interface 728, respectively. The drive and its associated computer-readable media provide a non-volatile storage device for computer-readable instructions, data structures, program modules, and other data for the computer. Although a hard disk, a removable disk, and a removable optical disk are described, other types of hardware-based computer-readable storage media can be used to store data, such as flash memory cards, digital video disks, RAM, ROM, and other hardware storage media.

[0113] Several program modules may be stored on a hard disk, a disk, an optical disk, a ROM, or a RAM. These programs include an operating system 730, one or more application programs 732, other programs 734, and program data 736. Application programs 732 or other programs 734 may include, for example, computer program logic (e.g., computer program code or instructions) for implementing server 102, servers 103A to 103N, computing device 112, control database 104, transaction coordination system 106, databases 108A to 108N, transaction driver 114, distributed transaction interface 302, transaction coordinator 304, persistent transaction table 312, control database 402, database 410, database 420, database 430, flowchart 200, flowchart 500, and / or flowchart 600 (including any suitable steps of flowchart 200, 500, or 600) and / or other embodiments described herein.

[0114] A user may enter commands and information into the computing device 700 through input devices such as a keyboard 738 and a pointing device 740. Other input devices (not shown) may include a microphone, a joystick, a game controller, a satellite dish, a scanner, a touch screen and / or touch pad, a voice recognition system for receiving voice input, a gesture recognition system for receiving gesture input, etc. These and other input devices are typically connected to the processor circuit 702 through a serial port interface 742 coupled to the bus 706, but may be connected through other interfaces such as a parallel port, a game port, or a universal serial bus (USB).

[0115] Display screen 744 is also connected to bus 706 via an interface, such as video adapter 746. Display screen 744 may be external to computing device 700 or incorporated into computing device 700. Display screen 744 may display information as well as serve as a user interface for receiving user commands and / or other information (e.g., by touch, finger gestures, a virtual keyboard, etc.). In addition to display screen 744, computing device 700 may include other peripheral output devices (not shown), such as speakers and printers.

[0116] The computing device 700 is connected to a network 748 (eg, the Internet) through an adapter or network interface 750, a modem 752, or other means for establishing communications over the network. Figure 7 As shown in FIG, modem 752 (which may be internal or external) may be connected to bus 706 via serial port interface 742, or may be connected to bus 706 using another type of interface including a parallel interface.

[0117] As used herein, the terms "computer program medium", "computer readable medium" and "computer readable storage medium" are used to refer to physical hardware media, such as a hard disk associated with hard disk drive 714, removable disk 718, removable optical disk 722, other physical hardware media, such as RAM, ROM, flash memory card, digital video disk, compact disk, MEM, nanotechnology-based storage devices, and other types of physical / tangible hardware storage media. Such computer readable storage media are different from (not including) communication media and do not overlap with communication media. Communication media embody computer readable instructions, data structures, program modules or other data in a modulated data signal (such as a carrier wave). The term "modulated data signal" means a signal having one or more of its characteristics set or changed in a manner with respect to encoding the information in the signal. By way of example and not limitation, communication media include wireless media (such as acoustic, RF, infrared and other wireless media) and wired media. Embodiments also relate to such communication media, which are separate and non-overlapping from the embodiments involving computer readable storage media.

[0118] As mentioned above, computer programs and modules (including application programs 732 and other programs 734) can be stored on a hard disk, disk, optical disk, ROM, RAM or other hardware storage medium. Such computer programs can also be received via network interface 750, serial port interface 742 or any other interface type. Such computer programs, when executed or loaded by an application, enable computing device 700 to implement the features of the embodiments described herein. Therefore, such computer programs represent controllers of computing device 700.

[0119] Embodiments also relate to computer program products including computer codes or instructions stored on any computer readable medium. Such computer program products include hard drives, optical drives, memory device packages, portable memory sticks, memory cards, and other types of physical storage hardware.

[0120] IV. Example Embodiments

[0121] A system for coordinating distributed transactions is disclosed herein. The system includes: at least one processor; and a memory storing program code configured to be executed by at least one processor, the program code including: a distributed transaction interface configured to: receive a driver report from a transaction driver, the driver report including a global identifier of the distributed transaction, a transaction driver identifier, and a plurality of participant identifiers, each participant identifier identifying a participant that is a part of a descendant of the transaction driver and responsible for the distributed transaction; determine whether a participant report is received from each of the plurality of participants, each participant report including a global identifier, a participant identifier of the participant, an identifier of any descendant participant identifier that identifies a descendant of the participant, and a state of a portion of the distributed transaction of the participant; a transaction coordinator configured to: store the global identifier, the plurality of participant identifiers, any descendant participant identifiers of each participant in a table and store the state of the portion of the distributed transaction of the participant for each participant that sent the participant report; determine the result of the distributed transaction using the table; and send the result to at least one of the participants.

[0122] In one implementation of the foregoing system, the table is a lock-free hashmap that includes an indication of whether each participant or descendant participant was added by a parent entity or a descendant entity.

[0123] In another implementation of the foregoing system, the transaction coordinator is configured to send the result to one of the participants in response to receiving a request from the participant.

[0124] In another implementation of the foregoing system, the global identifier is a unique identifier of the distributed transaction generated by the transaction driver.

[0125] In another implementation of the foregoing system, the distributed transaction interface is configured to receive a descendant participant report from at least one descendant of a participant, the descendant participant report including a global identifier, a descendant participant identifier of the descendant participant, an identification of any additional descendant participant identifiers, and a status of a portion of the distributed transaction of the descendant participant.

[0126] In another implementation of the foregoing system, an outcome of the distributed transaction is determined by the transaction coordinator to be an aborted transaction based on at least one of the following operations: failure to receive a participant report from at least one of the participants or descendant participants after a predetermined time period, or receiving a participant report from one of the participants or descendant participants, the participant report indicating that a portion of the distributed transaction of the participant or descendant participant has been aborted.

[0127] In another implementation of the foregoing system, the result of the distributed transaction is a committed transaction; and the transaction coordinator is configured to store the result in a persistent table.

[0128] A method for coordinating distributed transactions is disclosed herein. The method includes: receiving a driver report from a transaction driver, the driver report including a global identifier of the distributed transaction, a transaction driver identifier, and a plurality of participant identifiers, each participant identifier identifying a participant that is a part of a descendant of the transaction driver and responsible for the distributed transaction; determining whether a participant report is received from each of the plurality of participants, each participant report including a global identifier, a participant identifier of the participant, an identifier of any descendant participant identifier that identifies a descendant of the participant, and a state of the participant's portion of the distributed transaction; storing the global identifier, the plurality of participant identifiers, any descendant participant identifiers of each participant in a table and storing the state of the participant's portion of the distributed transaction for each participant that sent the participant report; determining a result of the distributed transaction using the table; and sending the result to at least one of the participants.

[0129] In one implementation of the foregoing method, the table is a lock-free hashmap that includes an indication of whether each participant or descendant participant was added by a parent entity or a descendant entity.

[0130] In another implementation of the aforementioned method, sending includes: sending the result to one of the participants in response to receiving a request from the participant.

[0131] In another implementation of the aforementioned method, the global identifier is a unique identifier of the distributed transaction generated by a transaction driver.

[0132] In another implementation of the foregoing method, the method further includes: receiving a descendant participant report from at least one descendant of the participant, the descendant participant report including a global identifier, a descendant participant identifier of the descendant participant, an identification of any additional descendant participant identifiers, and a status of a portion of the descendant participant's distributed transaction.

[0133] In another implementation of the foregoing method, using a table to determine an outcome of a distributed transaction includes determining the outcome of the distributed transaction as an aborted transaction based on at least one of the following operations: failing to receive a participant report from at least one of the participants or descendant participants after a predetermined time period, or receiving a participant report from one of the participants or descendant participants, the participant report indicating that a portion of the distributed transaction of the participant or descendant participant has been aborted.

[0134] In another implementation of the foregoing method, using the table to determine the result of the distributed transaction includes: determining the result of the distributed transaction as a committed transaction; and storing includes: storing the result in a persistent table.

[0135] A computer-readable memory is disclosed herein. The computer-readable memory includes computer program code recorded thereon, which, when executed by at least one processor, causes the at least one processor to execute a method, the method comprising: receiving a driver report from a transaction driver, the driver report including a global identifier of a distributed transaction, a transaction driver identifier, and a plurality of participant identifiers, each participant identifier identifying a participant that is a part of a descendant of the transaction driver and responsible for the distributed transaction; determining whether a participant report is received from each of the plurality of participants, each participant report including a global identifier, a participant identifier of the participant, an identifier of any descendant participant identifier that identifies a descendant of the participant, and a state of a portion of the distributed transaction of the participant; storing the global identifier, the plurality of participant identifiers, any descendant participant identifiers of each participant in a table and storing the state of the portion of the distributed transaction of the participant for each participant that sent the participant report; determining a result of the distributed transaction using the table; and sending the result to at least one of the participants.

[0136] In one implementation of the aforementioned computer readable memory, the table is a lock-free hash map that includes an indication of whether each participant or descendant participant was added by a parent entity or a descendant entity.

[0137] In another implementation of the foregoing computer-readable memory, sending includes: sending the result to one of the participants in response to receiving a request from the participant.

[0138] In another implementation of the aforementioned computer-readable memory, the method also includes: receiving a descendant participant report from at least one descendant of the participant, the descendant participant report including the global identifier, the descendant participant identifier of the descendant participant, an identification of any additional descendant participant identifiers, and the status of a portion of the distributed transaction of the descendant participant.

[0139] In another implementation of the aforementioned computer-readable memory, using a table to determine an outcome of a distributed transaction includes determining the outcome of the distributed transaction as an aborted transaction based on at least one of the following operations: failing to receive a participant report from at least one of the participants or descendant participants after a predetermined time period, or receiving a participant report from one of the participants or descendant participants, the participant report indicating that a portion of the distributed transaction of the participant or descendant participant has been aborted.

[0140] In another implementation of the foregoing computer-readable memory, using the table to determine the result of the distributed transaction includes: determining the result of the distributed transaction as a committed transaction; and storing includes: storing the result in a persistent table.

[0141] V. Conclusion

[0142] Although various embodiments of the present invention have been described above, it should be understood that they are presented by way of example only and not by way of limitation. (Multiple) persons skilled in the relevant art should understand that various changes can be performed in form and detail in the present invention without departing from the spirit and scope of the present invention as defined by the appended claims. Therefore, the breadth and scope of the present invention should not be limited by any of the exemplary embodiments described above, but should only be limited according to the following claims and their equivalents.

Claims

1. A system for coordinating distributed transactions, the system comprising: at least one processor; as well as A memory storing a program code configured to be executed by the at least one processor, the program code comprising: The transaction coordination system is configured to: receiving a first participant report from a first participant in a distributed transaction, the first participant report comprising a global identifier of the distributed transaction, a first participant identifier of the first participant, and a status of the first participant's portion of the distributed transaction; initiating generation of a table representing a hierarchical structure of the distributed transaction corresponding to the global identifier, the table indicating the first party identifier, the state of the portion of the distributed transaction of the first party, and an indication that the first party is identified as a party to the distributed transaction by a parent entity; receiving a driver report from a transaction driver that initiated the distributed transaction, the driver report comprising the global identifier, a transaction driver identifier, and the first participant identifier, wherein the driver report is received after the first participant report is received; In response to receiving the driver report, updating the table for the distributed transaction corresponding to the global identifier to: identifying the transaction driver identifier, and changing the indication that the first party is identified by a parent entity as a participant in the distributed transaction to an indication that the first party is in a confirmed state; using the table to determine an outcome of the distributed transaction; and The result is sent to the first party.

2. The system of claim 1, wherein the table is a lock-free hash map. 3 . The system of claim 1 , wherein the transaction coordination system is configured to send the result to the first party in response to receiving a request from the first party. 4 . The system of claim 1 , wherein the global identifier is a unique identifier of the distributed transaction generated by the transaction driver.

5. A system according to claim 1, wherein the transaction coordination system is configured to receive a descendant participant report from at least one descendant of the first participant, the descendant participant report including the global identifier, the descendant participant identifier of the descendant participant, an identification of any additional descendant participant identifiers, and the status of the portion of the distributed transaction of the descendant participant.

6. The system of claim 1 , wherein the result of the distributed transaction is determined by the transaction coordination system to be an aborted transaction based on at least one of: Failure to receive a participant report from a participant in the distributed transaction after a predetermined period of time, or A participant report is received from any participant of the distributed transaction, the participant report indicating that a portion of the distributed transaction has been aborted.

7. The system of claim 1 , wherein the result of the distributed transaction is a committed transaction; and The transaction coordination system is configured to store the result in a persistent table.

8. A method for coordinating distributed transactions, the method comprising: receiving a first participant report from a first participant in a distributed transaction, the first participant report comprising a global identifier of the distributed transaction, a first participant identifier of the first participant, and a status of the first participant's portion of the distributed transaction; initiating generation of a table representing a hierarchical structure of the distributed transaction corresponding to the global identifier, the table indicating the first party identifier, the state of the portion of the distributed transaction of the first party, and an indication that the first party is identified as a party to the distributed transaction by a parent entity; receiving a driver report from a transaction driver that initiated the distributed transaction, the driver report comprising the global identifier, a transaction driver identifier, and the first participant identifier, wherein the driver report is received after the first participant report is received; In response to receiving the driver report, updating the table for the distributed transaction corresponding to the global identifier to: identifying the transaction driver identifier, and changing the indication that the first party is identified by a parent entity as a participant in the distributed transaction to an indication that the first party is in a confirmed state; using the table to determine an outcome of the distributed transaction; as well as The result is sent to the first party.

9. The method of claim 8, wherein the table is a lock-free hash map.

10. The method of claim 8, wherein the sending comprises: The result is sent to the first party in response to receiving a request from the first party.

11. The method of claim 8, wherein the global identifier is a unique identifier of the distributed transaction generated by the transaction driver.

12. The method according to claim 8, further comprising: Receive a descendant participant report from at least one descendant of the first participant, the descendant participant report including the global identifier, a descendant participant identifier of the descendant participant, an identification of any additional descendant participant identifiers, and a status of the descendant participant's portion of the distributed transaction.

13. The method of claim 8, wherein using the table to determine the outcome of the distributed transaction comprises: The outcome of the distributed transaction is determined to be an aborted transaction based on at least one of: Failure to receive a participant report from a participant in the distributed transaction after a predetermined period of time, or A participant report is received from any participant of the distributed transaction, the participant report indicating that a portion of the distributed transaction has been aborted.

14. The method of claim 8, wherein using the table to determine the outcome of the distributed transaction comprises: Determining the result of the distributed transaction as the committed transaction; as well as The results are stored in a persistent table.

15. A computer readable memory having a computer program code recorded thereon, which, when the computer program code is executed by at least one processor, causes the at least one processor to perform the following method, the method comprising: receiving a first participant report from a first participant in a distributed transaction, the first participant report comprising a global identifier of the distributed transaction, a first participant identifier of the first participant, and a status of the first participant's portion of the distributed transaction; initiating generation of a table representing a hierarchical structure of the distributed transaction corresponding to the global identifier, the table indicating the first party identifier, the state of the portion of the distributed transaction of the first party, and an indication that the first party is identified as a party to the distributed transaction by a parent entity; receiving a driver report from a transaction driver that initiated the distributed transaction, the driver report comprising the global identifier, a transaction driver identifier, and the first participant identifier, wherein the driver report is received after the first participant report is received; In response to receiving the driver report, updating the table for the distributed transaction corresponding to the global identifier to: identifying the transaction driver identifier, and changing the indication that the first party is identified by a parent entity as a participant in the distributed transaction to an indication that the first party is in a confirmed state; using the table to determine an outcome of the distributed transaction; as well as The result is sent to the first party.

16. The computer readable memory of claim 15, wherein the table is a lock-free hash map.

17. The computer readable memory of claim 15, wherein the sending comprises: The result is sent to the first party in response to receiving a request from the first party.

18. The computer readable memory of claim 15, further comprising: Receive a descendant participant report from at least one descendant of the first participant, the descendant participant report including the global identifier, a descendant participant identifier of the descendant participant, an identification of any additional descendant participant identifiers, and a status of the descendant participant's portion of the distributed transaction.

19. The computer readable memory of claim 15, wherein using the table to determine the outcome of the distributed transaction comprises: The outcome of the distributed transaction is determined to be an aborted transaction based on at least one of: Failure to receive a participant report from a participant in the distributed transaction after a predetermined period of time, or A participant report is received from any participant of the distributed transaction, the participant report indicating that a portion of the distributed transaction has been aborted.

20. The computer readable memory of claim 15, wherein using the table to determine the outcome of the distributed transaction comprises: Determining the result of the distributed transaction as the committed transaction; as well as The results are stored in a persistent table.

Images