WO2016148716A1

WO2016148716A1 - Post in-doubt transaction to notice unit

Info

Publication number: WO2016148716A1
Application number: PCT/US2015/021410
Authority: WO
Inventors: Shang-Sheng Tung; Sean L. BROEDER; Oliver BUCAOJIT; John Deroo; Narendra Goyal; Trina R. Wisler-Krug; Adriana C. FUENTES; Ronald M. Cassou
Original assignee: Hewlett Packard Enterprise Development LP
Current assignee: Hewlett Packard Enterprise Development LP
Priority date: 2015-03-19
Filing date: 2015-03-19
Publication date: 2016-09-22
Anticipated expiration: 2017-09-19

Abstract

Recovery information is posted to a notice unit by a data store unit to indicate that a commitment of a transaction is in-doubt at the data store unit. A transaction unit is to monitor the recovery information at the notice unit. The transaction unit is to indicate to the data store unit to one of commit and abort the in-doubt transaction, if the transaction unit determines there is recovery information related to the in-doubt transaction at the notice unit.

Description

POST IN-DOUBT TRANSACTION TO NOTICE UNI!T

BACKGROUND

[0001 ] Transaction support is an area attracting attention in big table environments recently. Providing efficient transactional access across different data stores on big table ecosystem (e.g. Hadoop) while maintaining necessary isolation and consistency between transactions is becoming increasingly important.

B EF DESCRIPTION OF THE DRAWINGS

[0002] The foilowing detailed description references the drawings, wherein:

[0003] FIG. 1 is an example block diagram of a system to post an in-doubt transaction to a notice unit;

[0004] FIG. 2 is another example block diagram of a system to post an in-doubt transaction to a notice unit;

[0005] FIG. 3 is an example block diagram of a computing device including instructions for posting an in-doubt transaction to a notice unit; and

[0006] FIG. 4 is an example flowchart of a method for posting an in-doubt transaction to a notice unit.

DETAILED DESCRIPTSO

[0007] Specific details are given in the following description to provide a thorough understanding of embodiments. However, it will be understood that embodiments may be practiced without these specific details. For example, systems may be shown in block diagrams in order not to obscure embodiments in unnecessary detail. In other instances, well-known processes, structures and techniques may be shown without unnecessary detail in order to avoid obscuring embodiments.

[0008] Data stores usually have their own processes to recover from a crash (e.g. HBase utilizes the HLOG to perform row-level WAL). For a transaction spanning across multiple data stores, this may generally require a transaction manager (TM) to coordinate the transaction commit processing and resolve any in- doubt transaction if failures occur. A resource manager (RM) within the data store (e.g. Transactional Data Store (TDS)) may identify a list of such in-doubt transactions. A transaction spanning multiple stores could be committed in some data stores, but may be un-deterministic in other data stores (e.g. due to message being lost, process/node failure, system crash) and require a coordination between the TM and the RM (within the TDS) to resolve it.

[0009] Traditionally, the TM is asked to perform recovery on all the known TDSs (such as via a full broadcast) during restart, or the TM is asked to keep track of the TDSs and to monitor if there is a failure or an exception and then try to recover them. These requirements usually ask the TM to perform additional work and degrade the efficiency in transaction processing (e.g. usually latency may increase), in addition, it may also restrict the flexibility of TDS to relocate, split, or move for performance, capacity, or failure consideration. In a big table environment the number of transactional data stores and its server location could be changed dynamically. So it may be complicated to have the TM broadcast the recover request to ail the transactional data stores or monitor the status of entire data stores. Also, as the number of RMs (within the transactional data store) could be very large, running recovery against all the regions from all the TMs might not be very efficient,

[0010] During traditional system recovery, when the system restarts, the TM initiates the system recovery. The TM collects a list of all the configured RMs and broadcasts the recover requests to ail of them. Each individual RM exercises its own recovery mechanism (e.g. perform REDO (audit replay) to reconstruct the before-crash-image, including missing data writes and in-doubt (and in-flight) transactions). This in-doubt transaction list is then replied back to the TM. After consulting with persistent transaction state log, the TM will determine the outcome of each in-doubt transaction, and then drive the 2nd phase of commit processing to resolve the in-doubt transactions (either commit or abort). After all the in-doubt transactions have completely resolved (committed or rolled-back), system is recovered and then new transactions can be started.

[001 1 ] However, the system recovery on large data store might need to consider the following issues. First, there may be no master TM to drive the system recovery. The system recovery may be initiated and managed by the individual TM, which has its own transactional log to handle transaction resolution. Having a centralized TM to manager all the transactional work and recovery may also create a performance bottleneck and lack well scale out property. Second, the resource manager exercising recovery could be running on top of the data stores (e. region in HBase). One problem is that there may be far more number of RMs to manage compared to those on traditional system. In addition, the data store (e.g. region in HBase) could be moved from one server to another for load balance or capacity reason (relocated or split dynamically due to performance or utilization consideration), or be reopened and recovered in a different server due to a failure in the original hosting server process or physical node. With these issues, the traditional way to perform recovery might become inappropriate and cannot well manage different types of failures efficiently.

[0012] Instead of the pushing the recovery requests to all the configured R s, as used by the traditional method, examples may provide a pulling approach to perform transactional recovery in a large scale distributed data store (SQL or NOSQL) against failures, such as via a registration-based mechanism that has the RM inform the TM if the RM decides it has questions at hand (e.g. a need to resolve an in-doubt transaction from crash, or a need to check why a prepared transaction branch stays too long). With this approach, examples may resolve the inefficiency and the complexity traditional recovery encountered under the environment of large data stores. This approach may provide better scalability and extensibility in a large data store since the number of RMs could be very large and the set of R s could be dynamic (e.g. due to automatic data sharding for load balance, capacity, or elasticity).

[0013] in one example, recovery information may be posted to a notice unit by a data store unit to indicate that a commitment of a transaction is in-doubt at the data store unit. A transaction unit may monitor the recovery information at the notice unit. The transaction unit may indicate to the data store unit to one of commit and abort the in-doubt transaction, if the transaction unit determines there is recovery information related to the in-doubt transaction at the notice unit.

[0014] Thus, examples may be more scalable and have a better capability to manage a very large number of data stores across the distributed environment. Also, examples may be idempotent in that they may handle repeated failure during recovery. Further, examples may handle multiple failures in a distributed way. Examples may not need to have a centralized TM to synchronize or coordinate the transaction processing or perform recovery. Since there is no need for centralized transactional control, this may yield better performance, and it may be easier to manage possible splitting issues on transaction commit processing, in addition, examples may not require the TM to monitor the status of the entire system.

[0015] Examples may use a no-waited protocol, which may reduce any inefficiency introduced by traditional recovery scheme. By using a demand-driven approach, examples may reduce the number of messages transmitted. Examples may provide a uniform infrastructure for transactional recovery against several types of failures like data server process failure, node failure, TM failure, or system crash.

[0016] Referring now to the drawings, FIG. 1 is an example block diagram of a system 100 to post an in-doubt transaction to a notice unit. The system 100 may include a microprocessor, a controller, a memory module or device, a notebook computer, a desktop computer, an all-in-one system, a server, a network device, a wireless device, a storage device or any other type of device capable of interacting with a device in a distributed network.

[0017] The system 100 is shown to include a notice unit 1 10 and a transaction unit 120. The notice and transaction units 1 10 and 120 may include, for example, a hardware device including electronic circuitry for implementing the functionality described below, such as control logic and/or memory. In addition or as an alternative, the notice and transaction units 1 10 and 120 may be implemented as a series of instructions encoded on a machine-readable storage medium and executable by a processor.

[0018] The notice unit 1 10 may store recovery information 1 12. The recovery information 1 12 may be posted to the notice unit 1 10 by at least one of a plurality of data store units to indicate that a commitment of a transaction is in-doubt at the at least one data store unit. The transaction unit 120 may monitor the recovery information 1 12 at the notice unit 1 10. The transaction unit 120 may indicate to the at least one data store unit to one of commit and abort the in-doubt transaction 1 14, if the transaction unit 120 determines there is recovery information 1 12 related to the in-doubt transaction 1 14 at the notice unit 1 10. The notice 1 10 and transaction units 1 10 and 120 are described in further detail below with respect to FIG. 2.

[0019] FIG. 2 is another example block diagram of a system 200 to post an in- doubt transaction to a notice unit. The system 200 may include a microprocessor, a controller, a memory module or device, a notebook computer, a desktop computer, an ail-in-one system, a server, a network device, a wireless device, a storage device or any other type of device capable of interacting with a device in a distributed network.

[0020] The system 200 of FIG. 2 may include at least the functionality and/or hardware of the system 100 of FIG. 1 , For example, the system 200 is shown to include a notice unit 210 and a transaction unit 220. The notice unit 210 of the system 200 of FIG. 2 may include at least the functionality and/or hardware of the notice unit 1 10 of the system 100 of FIG. 1 and the transaction unit 220 of the system 200 of FIG. 2 may include at least the functionality and/or hardware of the transaction unit 120 of the system 100 of FIG. 1.

[0021 ] The system 200 is also shown to include a plurality of data store units 232-1 to 232-n, where n is a natural number. A data store unit 232 may include a repository of a set of data objects. These objects may be modelled using classes defined in a database schema. The data store unit 232 may include not only repositories like databases, but also simpler store types such as flat files etc. The data stores units 232 may include, for example, simple files like a spreadsheet, file systems, email storage systems (both server and client systems), databases, relational databases such as MySQL, PostgreSQL, Microsoft SQL Server, and Oracle Database, Object-oriented databases such as Cache or ConceptBase, distributed data stores such as Apache Cassandra, Druid (open-source data store) and Dynamo, directory services, and a file that stores a virtual machine.

[0022] The data store units 232 include any electronic, magnetic, optical, or other physical storage device that contains or stores information, such as Random Access Memory (RAM), an Electrically Erasable Programmable Readonly Memory (EEPROM), a storage drive, a Compact Disc Read Only Memory (CD-ROM), and the like. Further, each of the data store units 232 may include one or more TDS, which may further include one or more RMs. An example of an RM might be a database (like Oracle, DB2, SQL Server) or a transactional message queue (like IBM MQSeries or Microsoft Message Queue).

[0023] Transaction processing is information processing that is divided into individual, indivisible operations, called transactions. Each transaction must succeed or fail as a complete unit; it can never be only partially complete. A transaction comprises a unit of work performed within a database management system (or similar system) against a database, and treated in a coherent and reliable way independent of other transactions. A transaction generally represents any change in database.

[0024] A distributed transaction is a database transaction in which two or more network hosts are involved. Usually, hosts provide transactional resources, while the transaction manager is responsible for creating and managing a global transaction that encompasses all operations against such resources. Distributed transactions, as any other transactions, have all four ACID (atomicity, consistency, isolation, durability) properties, where atomicity guarantees all-or-nothing outcomes for the unit of work (operations bundle). The consistency property ensures that any transaction will bring the database from one valid state to another, e.g. only change affected data in allowed ways.

[0025] The isolation property ensures that the concurrent execution of transactions results in a system state that would be obtained if transactions were executed serially, i.e., one after the other. Durability means that once a transaction has been committed, it will remain so, even in the event of power loss, crashes, or errors. In a relational database, for instance, once a group of SQL statements execute, the results need to be stored permanently (even if the database crashes immediately thereafter). To defend against power loss, transactions (or their effects) must be recorded in a non-volatile memory. Durability can be achieved by flushing the transaction's log records to non-volatile storage before acknowledging commitment. [0026] In distributed transactions, all participating servers must coordinate before commit can be acknowledged. This is usually done by a two-phase commit protocol (2PC). The 2PC may be any type of atomic commitment protocol (ACP). It is a distributed algorithm that coordinates all the processes that participate in a distributed atomic transaction on whether to commit or abort (roll back) the transaction (it is a specialized type of consensus protocol). The protocol achieves its goal even in many cases of temporary system failure (involving either process, network node, communication, etc. failures).

[0027] Under 2PC, a single transaction can update many different databases or resources, and these resources may be distributed across networks, and have independent availability and failure modes. The two-phase commit strategy is designed to ensure that either all the resources are updated or none of them, so that the resources under transactional control remain synchronized. For example, the two-phase commit protocol requires a coordinator to maintain aii the information needed to recover the original state of the database if something goes wrong. As the name indicates there are two phases, voting and commit.

[0028] During the voting phase each node (e.g. participant, cohort or worker) writes the changes in the atomic commit to its own disk. The nodes then report their status to the coordinator, if any node does not report to the coordinator or their status message is lost the coordinator assumes the node's write failed. Once all of the nodes have reported to the coordinator the second phase begins. During the commit phase the coordinator sends a commit message to each of the nodes to record in their individual logs. Until this message is added to a node's log, any changes made will be recorded as incomplete, if any of the nodes reported a failure the coordinator will instead send a rollback message. This will remove any changes the nodes have written to disk.

[0029] As noted above, the notice unst 210 may store recovery information 1 12. The recovery information 1 12 may be posted to the notice unit 1 10 by at least one of a plurality of data store units 232-1 to 232-n to indicate that a commitment of a transaction 234 is in-doubt at the at least one data store unit 232-1. The in-doubt transaction 234 at one of the data store units 232-1 may be part of a transaction distributed among a plurality of the data store units 232-1 to 232-n.

[0030] The at least one data store unit 232-1 may identify the in-doubt transaction based on at least one of a crash, failure and delayed branch. The at least one data store unit 232-1 may reconstruct a state of the delayed branch based on at least one of a transaction identification number, an identity of the transaction unit 220, an undo log and a redo log.

[0031 ] The at least one data store unit 232-1 may store the recovery information 1 12 relating to the in-doubt transaction 234 to the notice unit 210 only if the recovery information 1 12 of the data store unit 232-1 is not posted at the notice unit 210. For example, the first data store unit 232-1 may first check if the transaction 234 is posted as being in-doubt at the first data store unit 232-1 before posting the in-doubt transaction 234 to the notice unit 210.

[0032] The transaction unit 220 may monitor the recovery information 1 12 at the notice unit 210. The transaction unit 220 may request to the data store unit 232-1 that stored the recovery information 210 to the notice unit 210 to provide any in-doubt transactions 234 at the data store unit 232-1 . For example, there may be a plurality of transactions 234 that are in-doubt at the first data store unit 232-1 , and not just the in-doubt transaction 234 of the first data store unit 232-1 that the transaction unit 220 noticed at the notice unit 210.

[0033] The transaction unit 220 may add any in-doubt transactions 234 related to recovery information 1 12 posted at the notice unit 210 to an in-doubt transaction list 222. For instance, the transaction unit 220 may receive three additional in-doubt transactions 234 for the first data store unit 232-1 , which are then added to the in-doubt transaction list 222.

[0034] Further, the transaction unit 220 may request any in-doubt transactions 234 from each of the data store units associated with each of the in-doubt transactions 234 of the in-doubt transaction list 222. For example, the transaction unit 220 may request ail in-doubt transactions 234 from each of the data store units 232 associated with an in-doubt transaction 234 of the in-doubt transaction list 222, to have a more complete list of ail in-doubt transactions 234. These in- doubt transactions 234 are replied back to the transaction unit 220.

[0035] The transaction unit 220 may build a transaction state table 224 based on a response from each of the data store units 232-1 to 232-n to the request for any in-doubt transactions 234. The transaction state table 224 may determine any in-doubt distributed transactions based on a plurality of the data store units 232-1 to 232-n reporting a same transaction as being in-doubt in response to the request. For example, assume that the transaction unit 220 previously carried out three distributed transactions. Based on the collected in-doubt transactions 234 from the request, the transaction state table 224 may reflect the following states: the first distributed transaction may be in-doubt at the first and third data store units 231 -1 and 232-3, the second distributed transaction may be in-doubt at the second data store unit 232-2 and the third distributed transaction may be in-doubt at the fourth, fifth and sixth data store units 232-4, 232-5 and 232-6, [0036] The transaction unit 220 may read a persistent transaction state log 226 to determine an outcome for each of the in-doubt distributed transactions of the transaction state table 224. The persistent transaction state log 226 may record a decision of the transaction unit 220 for previous transactions distributed among a plurality of data store units. The transaction unit 220 may indicate to commit the in-doubt transaction 234 to the at least one data store unit 232-1 , if the persistent transaction state log 226 includes an entry to commit the in-doubt distributed transaction.

[0037] On the other hand, the transaction unit 220 may indicate to abort the in-doubt transaction 234 to the at least one data store unit 232-1 , if the persistent transaction state iog 226 does not include an entry to the in-doubt distributed transaction or includes an entry to abort the in-doubt distributed transaction. For example, the persistent transaction state log 226 may indicate to commit the first distributed transaction, to abort the second distributed transaction, and lack an entry for the third distributed transaction.

[0038] The transaction unit 220 may not indicate to one of abort and commit to a remainder of data store units 232 included in the distributed transaction that did not store recovery information to the notice unit 210. For example, transaction unit 220 may indicate the for the first and third data store units 232-1 and 232-3 to commit the in-doubt transaction 234 for the first distributed transaction, but not send any indication to the second and fourth data store units 232-2 and 232-4, even though they are part of the same first distributed transaction. In this case, the second and fourth data store units 232-2 and 232-4 do not have any in-doubt transactions 234 with respect to the first distributed transaction.

[0039] The at least one data store unit 232-1 may remove the recovery information 1 12 related to the in-doubt transaction 232 after one of committing and aborting the in-doubt transaction 234. The data store unites 232 may be able to exercise the standard commit processing based on the aiready reconstructed prepared transaction branch. Therefore, a database consistency is maintained for this transaction spanning multiple data stores after failures.

[0040] While the system 200 is shown to include a single notice 210 unit and a single transaction unit 220, examples may include a plurality of the notice units 210, a plurality of the transaction units 220 and a set of the plurality of data store units 232-1 to 232-n. Each subset of the set of data store units 232-1 to 232-n may correspond to a different one of the plurality of notice units 210 and a different one of the plurality of transaction units 220.

[0041 ] If the transaction unit 220 misses the removal of the recovery information (e.g. de-registration event) since it's asynchronous, and sends another recovery- request to that data store unit 232, there will be no in-doubt transactions at that data store unit 232. In this case, that data store unit 232 may reply with a null list or similar message to the transaction unit 220. Examples are no-waited and loosely- coupled, so there does not need to be any specific synchronization or coordination between processes (e.g. the notice and transaction units 210 and 220) or on different sub-systems. This may yield better compatibility over different versions of releases, and may be easier to apply the mechanism to different environments. [0042] For instance, examples may be applied to other failure cases, like to a server process hosting a data store unit 232 or a transaction unit 220 death. Recovery of the data store unit 232 (e.g. log splitting by the HMaster in HBase) may be performed in the similar way when the data store unit 232 migrates to a new server due to the hosting server process dying abruptly. When the data store unit 232 is re-opened, a similar recovery process may be executed. With a transaction unit 220 death, a transaction coordinator takeover process may be carried out via another transaction unit 220 to take over the commit responsibility from the down transaction unit 220, or with restarting the original transaction unit 220, in order to resolve the in-doubt transaction 234.

[0043] Thus, examples provide an efficient way to handle transactional recovery in big data environment with hundreds of data servers hosting many data shards. The decentralized and asynchronous approach of examples may yield better scalability and efficiency for transactional recovery and may manage the complexity from different types of failures (logical process or physical node) while maintaining the transaction ACID properties.

[0044] FIG. 3 is an example block diagram of a computing device 300 including instructions for posting an in-doubt transaction to a notice unit. In the embodiment of FIG. 3, the computing device 300 includes a processor 310 and a machine- readable storage medium 320. The machine-readable storage medium 320 further includes instructions 322, 324 and 326 for posting the in-doubt transaction to the notice unit (not shown).

[0045] The computing device 300 may be included in or part of, for example, a microprocessor, a controller, a memory module or device, a notebook computer, a desktop computer, an all-in-one system, a server, a network device, a wireless device, a storage device or any other type of device capable of executing the instructions 322, 324 and 328. in certain examples, the computing device 300 may include or be connected to additional components such as memories, controllers, etc.

[0046] The processor 310 may be, at least one central processing unit (CPU), at least one semiconductor-based microprocessor, at least one graphics processing unit (GPU), a microcontroller, special purpose logic hardware controlled by microcode or other hardware devices suitable for retrieval and execution of instructions stored in the machine-readable storage medium 320, or combinations thereof. The processor 310 may fetch, decode, and execute instructions 322 and 324 and 326 to implement posting the in-doubt transaction to the notice unit. As an alternative or in addition to retrieving and executing instructions, the processor 310 may include at least one integrated circuit (IC), other control logic, other electronic circuits, or combinations thereof that include a number of electronic components for performing the functionality of instructions 322, 324 and 326.

[0047] The machine-readable storage medium 320 may be any electronic, magnetic, optical, or other physical storage device that contains or stores executable instructions. Thus, the machine-readable storage medium 320 may be, for example, Random Access Memory (RAM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), a storage drive, a Compact Disc Read Only Memory (CD-ROM), and the like. As such, the machine-readable storage medium 320 can be non-transitory. As described in detail below, machine- readable storage medium 320 may be encoded with a series of executable instructions for posting the in-doubt transaction to the notice unit.

[0048] Moreover, the instructions 322, 324 and 326, when executed by a processor (e.g., via one processing element or multiple processing elements of the processor) can cause the processor to perform processes, such as, the process of FIG. 4. For example, the first request instructions 322 may be executed by the processor 310 to send a first request to each one of a plurality of data store units that posts an in-doubt transaction to the notice unit. The in-doubt transaction may indicate un-deterministic transaction at the corresponding data store unit. The first request may ask to return any other in-doubt transactions at the corresponding data store unit.

[0049] The determine instructions 324 may be executed by the processor 310 to determine which of the data store units have in-doubt transactions that are part of a same distributed transaction to form a list of in-doubt distributed transactions, based on a response to the first request. The second request instructions 326 may be executed by the processor 310 to send a second request to one of abort and commit each of the in-doubt transactions to each of the data store units that responded to the first request, based on a lookup of the in-doubt distributed transaction in a persistent transaction state log (not shown). The persistent transaction state log may record distributed transactions transmitted via a two- phase commit protocol (2PC).

[0050] FIG. 4 is an example flowchart of a method 400 for posting an in-doubt transaction to a notice unit. Although execution of the method 400 is described below with reference to the system 200, other suitable components for execution of the method 400 can be utilized, such as the system 100. Additionally, the components for executing the method 400 may be spread among multiple devices (e.g., a processing device in communication with input and output devices). In certain scenarios, multiple devices acting in coordination can be considered a single device to perform the method 400. The method 400 may be implemented in the form of executable instructions stored on a machine-readable storage medium, such as storage medium 320, and/or in the form of electronic circuitry.

[0051 ] At block 410, the data store unit 232-1 identifies that it has an in-doubt transaction 234. The in-doubt transaction 234 may be part of a distributed transaction that spans a plurality of data store units 230. Then, at block 420, the data store unit 232-1 posts the in-doubt transaction 234 to a notice unit 210, if the in-doubt transaction 234 is not posted to the notice unit 210. At block 430, the data store unit 232-1 sends ail in-doubt transactions 234 to a transaction unit 220 in response to a request.

[0052] The transaction unit 220 may send the request in response to the in-doubt transaction 234 being posted to the notice unit 210. Next, at block 440, the data store unit 232-1 one of commits and aborts the in-doubt transaction 234 in response to a command from the transaction unit 220. At block 450, the data store unit 232- 1 removes the in-doubt transaction 234 from the notice unit 210 after the in-doubt transaction 234 is one of committed and aborted.

Claims

CLASMS We claim:

1 . A system, comprising:

a notice unit to store recovery information, the recovery information to be posted to the notice unit by at least one of a plurality of data store units to indicate that a commitment of a transaction is in-doubt at the at least one data store unit; and

a transaction unit to monitor the recovery information at the notice unit, the transaction unit to indicate to the at least one data store unit to one of commit and abort the in-doubt transaction, if the transaction unit determines there is recovery information related to the in-doubt transaction at the notice unit,

2. The system of claim 1 , wherein,

the in-doubt transaction at the at least one data store unit is part of a transaction distributed among a plurality of the data store units, and

the transaction unit does not indicate to one of abort and commit to a remainder of data store units included in the distributed transaction that did not store recovery information to the notice unit.

3. The system of claim 2, wherein the transaction unit is to request to the data store unit that stored the recovery information to the notice unit to provide any in-doubt transactions at the data store unit.

4. The system of claim 3, wherein,

the transaction unit is to add any in-doubt transactions related to recovery information posted at the notice unit to an in-doubt transaction list and the transaction unit is to request any in-doubt transactions from each of the data store units associated with each of the in-doubt transactions of the in- doubt transaction list.

5. The system of claim 4, wherein,

the transaction unit is to build a transaction state table based on a response from each of the data store units to the request for any in-doubt transactions, and

the transaction state table is to determine any in-doubt distributed transactions based on a plurality of the data store units reporting a same transaction as being in-doubt in response to the request.

6. The system of claim 5, wherein,

the transaction unit is to read a persistent transaction state log to determine an outcome for each of the in-doubt distributed transactions of the transaction state table, and

the persistent transaction state log is to record a decision of the transaction unit for previous transactions distributed among a piuraiity of data store units.

7. The system of claim 6, wherein,

the transaction unit is to indicate to commit the in-doubt transaction to the at least one data store unit, if the persistent transaction state log includes an entry to commit the in-doubt distributed transaction, and

the transaction unit is to indicate to abort the in-doubt transaction to the at least one data store unit, if the persistent transaction state log at least one of does not include an entry to the in-doubt distributed transaction and includes an entry to abort the in-doubt distributed transaction.

8. The system of ciaim 7, wherein the at ieast one data store unit is to remove the recovery information related to the in-doubt transaction after one of committing and aborting the in-doubt transaction.

9. The system of ciaim 1 , wherein the at Ieast one data store unit is to store the recovery information relating to the in-doubt transaction to the notice unit only if the recovery information of the data store unit is not posted at the notice unit.

10. The system of ciaim 1 , wherein,

the at Ieast one data store unit is to identify the in-doubt transaction based on at Ieast one of a crash, failure and delayed branch, and

the at least one data store unit is to reconstruct a state of the delayed branch based on at Ieast one of a transaction identification number, an identity of the transaction unit, an undo log and a redo log.

1 1. The system of claim 1 , wherein,

the system includes a plurality of the notice units, a plurality of the transaction units and a set of the plurality of data store units, and

each subset of the set of data store units corresponds to a different one of the plurality of notice units and a different one of the plurality of transaction units,

12. A method, comprising:

identifying at a data store unit an in-doubt transaction, the in-doubt transaction to be pail of a distributed transaction that spans a plurality of data store units;

posting the in-doubt distributed transaction to a notice unit, if the in-doubt distributed transaction is not posted to the notice unit;

sending all in-doubt distributed transactions to a transaction unit in response to a request;

one of committing and aborting the in-doubt transaction in response to a command from the transaction unit; and

removing the in-doubt transaction from the notice unit after the in-doubt transaction is one of committed and aborted,

13. The method of claim 12, wherein the transaction unit is to send the request in response to the in-doubt transaction being posted to the notice unit.

14. A non-transitory computer-readable storage medium storing instructions thai if executed by a processor of a device, cause the processor to: send a first request to each one of a plurality of data store units that posts an in-doubt transaction to a notice unit, the in-doubt transaction to indicate un-deterministic transaction at the corresponding data store unit and the first request to ask to return any other in-doubt transactions at the corresponding data store unit;

determine which of the data store units have in-doubt transactions that are part of a same distributed transaction to form a list of in-doubt distributed transactions, based on a response to the first request; and

send a second request to one of abort and commit each of the in-doubt transactions to each of the data store units that responded to the first request, based on a lookup of the in-doubt distributed transaction in a persistent transaction state log,

15. The non-transitory computer-readable storage medium of claim 14, wherein persistent transaction state log is to record distributed transactions transmitted via a two-phase commit protocol (2PC).