TRANSACTIONS

BACKGROUND

[0001] In transaction processing, databases, and computer networking, a two- phase commit protocol is a type of atomic commitment protocol. An atomic commit may be described as an operation that applies a set of distinct changes as a single operation. The atomic commit may be denoted as having succeeded if the changes are applied, and if there is a failure before the atomic commit can be completed, all of the changes completed in the atomic commit are reversed. This aspect of reversal of all of the changes completed in the atomic commit may ensure that a system is left in a consistent state in the event of the failure. The atomic commit further includes the property of isolation where one atomic commit is processed at any given time. Atomic commits may be used, for example, in database systems, revision control systems, and other such areas.

BRIEF DESCRIPTION OF DRAWINGS

[0002] Features of the present disclosure are illustrated by way of example and not limited in the following figure(s), in which like numerals indicate like elements, in which:

[0003] Figure 1 illustrates a layout of a two-phase commit protocol mixing for distributed transactions apparatus, according to an example of the present disclosure;

[0004] Figure 2 illustrates an environment for the two-phase commit protocol mixing for distributed transactions apparatus of Figure 1 , according to an example of the present disclosure;

[0005] Figure 3 illustrates a flowchart of a method for implementing the two- phase commit protocol mixing for distributed transactions apparatus of Figure 1 , according to an example of the present disclosure;

[0006] Figure 4 illustrates another flowchart of a method for implementing the two-phase commit protocol mixing for distributed transactions apparatus of Figure 1 , according to an example of the present disclosure;

[0007] Figure 5 illustrates another flowchart of a method for implementing the two-phase commit protocol mixing for distributed transactions apparatus of Figure 1 , according to an example of the present disclosure; and

[0008] Figure 6 illustrates a computer system, according to an example of the present disclosure.

DETAILED DESCRIPTION

[0009] For simplicity and illustrative purposes, the present disclosure is described by referring mainly to examples. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. It will be readily apparent however, that the present disclosure may be practiced without limitation to these specific details. In other instances, some methods and structures have not been described in detail so as not to unnecessarily obscure the present disclosure.

[0010] Throughout the present disclosure, the terms "a" and "an" are intended to denote at least one of a particular element. As used herein, the term "includes" means includes but not limited to, the term "including" means including but not limited to. The term "based on" means based at least in part on.

[0011] In transaction processing, databases, computer networking, and other such areas, the two-phase commit protocol is a type of atomic commitment protocol that may be described as a distributed set of machine readable

instructions, where the two-phase commit protocol coordinates all of the processes that participate in a distributed atomic transaction on whether to commit or abort (i.e., roll back) the transaction. The two-phase commit protocol achieves its goal of committing a transaction even in many cases of temporary system failure, for example, involving failures of an associated process, a network node,

communication, etc. In order to accommodate recovery from failure, the two-phase commit protocol's participants may use logging of the two-phase commit protocol's states. In this regard, log records may be used by the two-phase commit protocol's recovery procedures.

[0012] Solutions using a two-phase commit protocol may include a data manipulation language phase (e.g., phase-0) where all of the transactional insert, update, and delete operations are performed. In implementations that use lock management (e.g., implemented by lock management modules), locks may be acquired and accumulated during the phase-0. Further to phase-0, an operation of a two-phase commit protocol may include a com m it-request phase (also referred to herein as a voting phase, prepare phase, or phase-1 ), and a commit phase (also referred to herein as phase-2). For participants implementing a presumed prepared protocol as disclosed herein, each data manipulation language operation may be evaluated as including an implied com m it-request phase (i.e., phase-1 ) so that the transaction is committable at any moment as long as none of the data manipulation language requests returned an error. Any error on the data

manipulation language request (after suitable retry where applicable) may result in an abort.

[0013] Locks may be described as the mechanism that prevents other concurrent transactions from modifying the underlying data while a current transaction is in process. Instead of or in addition to locks, a database may use optimistic concurrency control, and abort if a conflict was detected. Locks may continue to be held until the end of phase-2 as disclosed herein, after all data manipulation language operations are performed and safe stored into audit trails.

[0014] Audit records describing the data modifications may be placed into audit buffers in an audit service cache, but these audit buffers may not be flushed, or the audit records may be safe stored, for example, on a disk during the phase-0. Audit trails may provide for implementation of data persistence in a database. Audit records may be made persistent, for example, by a disk, solid state drive (SSD), non-volatile random access memory (RAM), n-copies, etc., before a transaction finishes phase-2 as disclosed herein, so that in the event of an unplanned outage, the audit records themselves may be used to reconstruct unapplied transactions and make the database consistent. In certain 2-phase commit protocols, the audit records are not flushed to disk and are held in memory until after the prepare phase (i.e., phase-1 ). In the presumed prepared case as disclosed herein, the audit records may be made persistent after each data manipulation language operation, thereby making the prepare message obsolete for those participants implementing the presumed prepared protocol. [0015] In the com m it-request phase (phase-1 as disclosed herein), a

coordinator process may attempt to prepare all of the participating processes (denoted participants, cohorts, or workers) of a transaction to take the needed steps for either committing or aborting the transaction, and to vote, either "Yes" (i.e., commit (if the transaction participant's local portion execution has ended properly)), or "No" (i.e., abort (if a problem has been detected with the transaction participant's local portion execution). In this regard, when a transaction is to be committed, the transaction may enter the phase-1 whereby a transaction

management module (e.g., that includes a coordinator process as disclosed herein) first sends a prepare message to all participating resource management modules (of the transaction participants) of the transaction. Alternatively, when a transaction is to be committed, the transaction may enter the phase-1 whereby the transaction management module (e.g., that includes a coordinator process as disclosed herein) first sends the prepare message to those participating resource management modules (of the transaction participants) of the transaction that do not implement a presumed prepared protocol as disclosed herein. For the phase-1 , every resource management module votes on the outcome of the transaction.

Each of the resource management modules may attempt to ready themselves to commit so that the transaction will be made durable in the event of a failure.

Implementations without lock management modules may compare the

modifications of the current transaction against modifications for other transactions to determine if a conflict between the transactions exists. If a conflict exists, the resource management module may reply back to the transaction management module with a vote to abort the transaction. If there are no conflicts, the resource management module may ensure that the audit is safe to disk by creating a prepared audit record, placing the audit record in an audit buffer, and force flushing the audit buffer cache. Lock management module implementations do not include a conflict detection component and flush the audit records for the modifications made to persistent memory. At this stage, the resource management module may be designated as being 'prepared', and the resource management module may reply back to the transaction management module that it is ready to commit.

[0016] In the commit phase (phase-2 as disclosed herein), based on the voting of the participants, the coordinator process decides whether to commit (if all participants have voted "Yes"), or abort the transaction (otherwise), and notifies the result to all of the participants. The participants may then follow with the needed actions (i.e., commit or abort) with their local transactional resources (also denoted as recoverable resources; e.g., database data). In this regard, after all of the resource management modules have replied back to the transaction management module from the prepare message, the transaction management module may trigger the phase-2. If any resource management module has voted to abort the transaction for any reason, the transaction will be aborted by the transaction management module, and the transaction management module will send abort messages to all resource management modules. If all of the resource

management modules have voted to commit, then the commit will be driven to the resource management modules. During the phase-2, the resource management modules will release locks (if any held), and cleanup resources held by the transaction.

[0017] According to examples, a 'presumed abort' protocol may be

implemented, whereby during recovery in the event of failure as disclosed herein, a resource management module that finds audit records for a transaction, but without 'prepared' audit records, would assume that the transaction is to be aborted. In certain implementations, a resource management module may roll such

transactions back, and in other implementations, a resource management module may wait for the transaction management module to tell the resource management module to abort the transactions. Resource management modules with

transactions in a prepared state are to wait for the transaction management module to re-drive either the commit or the abort to complete the phase-2.

[0018] If a resource management module fails prior to the transaction

completing phase-1 , the entire transaction is to be aborted. This is due to the uncertainty of whether all the needed audits generated by the resource

management module during the insert, update, and delete operations were flushed to disk prior to the resource management module failure.

[0019] With respect to a presumed prepared protocol, all participants may be assumed to implement the presumed prepared protocol. The presumed prepared protocol may provide for elimination of the phase-1 processing as a transaction transitions from phase-0 to phase-1 , as disclosed herein, and eliminates the need for the phase-1 messages sent from the transaction management module to all of the resource management modules. In this regard, each resource management module may maintain a permanent prepared state. When insert, update, and delete requests are received by a resource management module, the resource management module may perform both the phase-0 and the phase-1 tasks for each operation, i.e., acquiring locks if a lock management module is implemented, or if not, the resource management module performs conflict detection, and the audit records may be made persistent to an audit store. For this implementation, a lock management module may be implemented such that locks are obtained and held for the duration of a transaction to prevent conflicts, and if locks are not held, then conflicts are to be detected at the time of data modification so that a resource management module can notify the transaction management module to abort the transaction. After each insert, update, and delete operation, the resource management module may reply back to a client indicating the operation is complete and all resource management modules are perennially in a presumed prepared state with the exception of while an insert, update, and delete operation is in progress. When a client finishes all the insert, update, and delete operations needed for a transaction, and if no resource management module replies with an error, the transaction management module may immediately proceed with the phase-2 processing thereby avoiding all of the phase-1 message traffic previously needed.

[0020] In this regard, according to examples, a two-phase commit protocol mixing for distributed transactions apparatus and a method for two-phase commit protocol mixing for distributed transactions are disclosed herein. According to examples, the apparatus and method disclosed herein may provide for mixing of the presumed prepared protocol with other two-phase protocols to implement a two-phase commit process. For example, a transaction may span two separate databases whereby one database (or some participants in one database) implements the presumed prepared protocol and the other database does not. According to examples, the apparatus and method disclosed herein may allow a coordinator process to take advantage of the presumed prepared protocol when available, and still ensure that all branches of a transaction are consistent and durable. Even within the same database, some portions may have a different replication scheme or reside in geographically remote locations where the cost of some additional messages may be prohibitive. According to examples, the apparatus and method disclosed herein may allow a user to indicate which protocol is preferred, and for which data.

[0021] According to examples, the apparatus and method disclosed herein may provide a mechanism to commit distributed transactions with multiple participants without the need to send a prepare message in the phase-1 , for example, when all participants implement the presumed prepared protocol as disclosed herein. The apparatus and method disclosed herein may be used in a variety of environments, such as, for example, environments that include a plurality of participants, and environments where the message traffic is already high such that the marginal cost of additional remote procedure calls is high.

[0022] According to examples, the apparatus and method disclosed herein may provide for some participants to use the presumed prepared protocol while other participants do not. This aspect may be beneficial, for example, where a

transaction spans multiple domains where one domain has the presumed prepared protocol implemented while the other domain does not.

[0023] According to examples, the apparatus and method disclosed herein may provide a mechanism to mix different two-phase commit protocols for distributed transactions. For example, with respect to mixing of protocols, the apparatus and method disclosed herein may provide for gain of efficiencies, for example, by avoiding the com m it-request (prepare) message, and/or based on some (as opposed to none) of the participants implementing the presumed prepared protocol. According to examples, the transactions may span different clusters as well as different tables. With respect to transactions spanning different clusters and tables, as the amount of data for global customers becomes increasingly large, customers may not store all their data in one database, one datacenter, or one country. Often customers may need to update or query data coming from multiple distant regions. For distant participants, the cost of the message traffic may exceed the cost of additional local operations to make a presumed prepared protocol operate. Based, for example, on the use of the presumed prepared protocol as disclosed herein, the apparatus and method disclosed herein may provide for the implementation of commit and more resilient distributed

transactions, and allow different branches of a transaction to use different protocols. According to examples, for the apparatus and method disclosed herein, all participating branches in a transaction may benefit from the added resiliency provided by the presumed prepared protocol even if a specific branch does not itself use the presumed prepared protocol.

[0024] According to examples, the apparatus and method disclosed herein may provide for interoperability between disparate databases where, for example, one database has implemented the presumed prepared protocol, and the other database has not implemented the presumed prepared protocol. This aspect of interoperability between disparate databases may facilitate implementation of a migration strategy as a user shifts from one database vendor to another, as well as for providing an optimized two-phase commit strategy for transactions that span multiple systems.

[0025] According to examples, for the apparatus and method disclosed herein, when a transaction becomes more resilient to resource management module failures when more participants implement the presumed prepared protocol, even if some of the participants participate in the presumed prepared protocol, the entire transaction may include increased resiliency because fewer branches of the transaction are vulnerable to crashes after completing their work on behalf of a transaction.

[0026] According to examples, for the apparatus and method disclosed herein, with respect to use of the presumed prepared protocol, transactions need not be aborted simply because a participating resource management module fails during processing of a transaction. If the branch of the transaction owned by the failed resource management module was complete and had finished its insert, update, and delete operations, then the transaction may continue as if the resource management module were still active. The transaction management module may assume that a subsequent insert, update, and delete operation against the same resource management module would encounter an error either sending the insert, update, and delete request, or in the reply when the connection was broken. If an error occurs, a client may inform the transaction management module, and the transaction is aborted. If no error occurs, then the transaction may proceed to the phase-2. Although the transaction management module would receive an error sending the phase-2 commit message to the failed resource management module, the transaction management module may re-drive the phase-2 commit whenever the resource management module was restarted/recovered without a risk of data loss because the affected resource management module was already in a prepare state.

[0027] Figure 1 illustrates a layout of a two-phase commit protocol mixing for distributed transactions apparatus (hereinafter also referred to as "apparatus 100"), according to an example of the present disclosure. Figure 2 illustrates an environment 200 of the apparatus 100, according to an example of the present disclosure. [0028] Referring to Figures 1 and 2, the apparatus 100 may include a transaction management module 102 to determine, for a transaction 104 that includes a plurality of associated participants 106, whether all participants 106 implement, whether some participants 106 implement, or whether no participant implements a presumed prepared protocol. In response to a determination by the transaction management module 102 that all participants 106 implement, that some participants 106 implement, or that no participant implements the presumed prepared protocol, the transaction management module 102 may operate in conjunction with resource management modules 108 of the participants 106 to respectively implement a different procedure from a plurality of available

procedures for a two-phase commit process that includes a comm it-request phase (e.g., phase-1 ) and a commit phase (e.g., phase-2) to commit the transaction.

[0029] According to examples, the transaction management module 102 may determine, for the transaction 104 that includes the plurality of associated participants 106, whether all participants 106 implement, whether some

participants 106 implement, or whether no participant implements the presumed prepared protocol by analyzing responses to registration requests from each participant of the plurality of participants 106 for joining the transaction 104, and determining, based on the analysis of the responses to the registration requests from each participant of the plurality of participants 106 for joining the transaction 104, whether all participants 106 implement, whether some participants 106 implement, or whether no participant implements the presumed prepared protocol.

[0030] According to examples, in response to the determination by the transaction management module 102 that all participants 106 implement the presumed prepared protocol, the transaction management module 102 may operate in conjunction with the resource management modules 108 of the participants 106 to implement a procedure of the plurality of available procedures for the two-phase commit process by bypassing the comm it-request phase of the two-phase commit process for all participants of the plurality of participants 106, and implementing the commit phase of the two-phase commit process for all participants of the plurality of participants 106.

[0031] According to examples, in response to the determination by the transaction management module 102 that some participants 106 implement the presumed prepared protocol, the transaction management module 102 may operate in conjunction with the resource management modules 108 of the participants 106 to implement a procedure of the plurality of available procedures for the two-phase commit process by bypassing the comm it-request phase of the two-phase commit process for the some participants of the plurality of participants 106, sending prepare requests to remaining participants, other than the some participants, of the plurality of participants 106 that do not implement the presumed prepared protocol to implement the comm it-request phase of the two-phase commit process for the remaining participants, and implementing the commit phase of the two-phase commit process for all participants of the plurality of participants 106.

[0032] According to examples, in response to the determination by the transaction management module 102 that no participant implements the presumed prepared protocol, the transaction management module 102 may operate in conjunction with the resource management modules 108 of the participants 106 to implement a procedure of the plurality of available procedures for the two-phase commit process by sending prepare requests to all participants to implement the comm it-request phase of the two-phase commit process for all participants of the plurality of participants 106, and implementing the commit phase of the two-phase commit process for all participants of the plurality of participants 106.

[0033] According to examples, lock management modules 110 associated with the participants 106 may perform a data manipulation language phase (e.g., phase-0) prior to the comm it-request phase and the commit phase. The

transactional insert, update, and delete operations related to the transaction 104 may be performed at the data manipulation language phase.

[0034] The modules and other elements of the apparatus 100 may be machine readable instructions stored on a non-transitory computer readable medium. In this regard, the apparatus 100 may include or be a non-transitory computer readable medium. In addition, or alternatively, the modules and other elements of the apparatus 100 may be hardware or a combination of machine readable instructions and hardware.

[0035] The apparatus 100 may provide for the transaction management module 102 to ascertain which protocol is implemented by each of the participants 106. If a participant implements and is using the presumed prepared protocol, the participant may indicate the use of the presumed prepared protocol in a reply to a registration (e.g., participation) request when the participant joins a transaction 104.

[0036] The transaction management module 102 may keep track of the types of participants 106 it has for every transaction (e.g., participants that use the presumed prepared protocol, and participants that do not use the presumed prepared protocol).

[0037] When a client attempts to commit the transaction 104 and enter the phase-1 , if all of the participants 106 implement the presume prepared protocol, the transaction management module 102 may immediately enter the phase-2 as each of the participants 106 is assumed to have already completed conflict detection, flushed, and voted to commit. With respect to voting, at the end of every data manipulation language operation, the participant returns a reply to the client. If there was an error, this is assumed to be an abort request, or if no error, this is a "ready to commit" reply. Based on the successful completion of all data

manipulation language operations, phase-2 may be entered at any time. Based on the voting of the participants 106, the transaction management module 102 may decide whether to commit (if all participants have voted "Yes"), or abort the transaction (otherwise), and notifies the result to all of the participants 106. The participants 106 may then follow with the needed actions (i.e., commit or abort) with their local resource management module. [0038] If none of the participants 106 have indicated that they are implementing the presumed prepared protocol, then the transaction management module 102 may first enter the phase-1 , and send prepare requests to each of the participants 106. In this regard, the transaction management module 102 may attempt to prepare all of the par participants 106 of a transaction 104 to take the needed steps for either committing or aborting the transaction, and to vote, either "Yes" (i.e., commit (if the transaction participant's local portion execution has ended properly)), or "No" (i.e., abort (if a problem has been detected with the transaction participant's local portion execution). Thereafter, processing may proceed to phase-2 as disclosed herein.

[0039] If some of the participants 106 are using the presumed prepared protocol and other participants are not, then the transaction management module 102 may bypass the participants (or participant) that are implementing the presumed prepared protocol as they are already prepared, and send the prepare requests to the participants that are not using the presumed prepared protocol and are otherwise using a different two-phase commit protocol. In this way, all of the participants 106 are known to have prepared and flushed before the transaction enters the phase-2.

[0040] Figures 3-5 respectively illustrate flowcharts of methods 300, 400, and 500 for implementation of a two-phase commit protocol mixing for distributed transactions, corresponding to the example of the two-phase commit protocol mixing for distributed transactions apparatus 100 whose construction is described in detail above. The methods 300, 400, and 500 may be implemented on the two- phase commit protocol mixing for distributed transactions apparatus 100 with reference to Figures 1 and 2 by way of example and not limitation. The methods 300, 400, and 500 may be practiced in other apparatus. The example of Figure 4 may represent a method that is implemented on the apparatus 100 that includes a processor 602 (see Figure 6), and a memory 606 (see Figure 6) storing machine readable instructions that when executed by the processor cause the processor to perform the method 400. The example of Figure 5 may represent a non-transitory computer readable medium having stored thereon machine readable instructions to implement a two-phase commit protocol mixing for distributed transactions, the machine readable instructions, when executed, cause a processor (e.g., the processor 602 of Figure 6) to perform the method 500.

[0041] Referring to Figures 1 -3, for the method 300, at block 302, the method may include identifying, for a transaction 104 that includes a plurality of associated participants 106, which participants of the plurality of participants 106 implement a presumed prepared protocol.

[0042] At block 304, the method may include determining, based on the identification, whether all participants implement, whether some participants implement, or whether no participant implements the presumed prepared protocol.

[0043] At block 306, in response to a determination that all participants implement, that some participants implement, or that no participant implements the presumed prepared protocol, the method may include respectively implementing a different procedure from a plurality of available procedures for a two-phase commit process that includes a com m it-request phase and a commit phase to commit the transaction.

[0044] According to examples, the method 300 may include performing a data manipulation language phase prior to the com m it-request phase and the commit phase, where transactional insert, update, and delete operations related to the transaction 104 are performed at the data manipulation language phase.

[0045] According to examples, for the method 300, determining, based on the identification, whether all participants implement, whether some participants implement, or whether no participant implements the presumed prepared protocol, may further include analyzing responses to registration requests from each participant of the plurality of participants 106 for joining the transaction 104, and determining, based on the analysis of the responses to the registration requests from each participant of the plurality of participants 106 for joining the transaction 104, whether all participants implement, whether some participants implement, or whether no participant implements the presumed prepared protocol.

[0046] According to examples, in response to the determination that all participants implement the presumed prepared protocol, the method may include implementing a procedure of the plurality of available procedures for the two-phase commit process by bypassing the com m it-request phase of the two-phase commit process for all participants of the plurality of participants 106, and implementing the commit phase of the two-phase commit process for all participants of the plurality of participants 106.

[0047] According to examples, in response to the determination that some participants implement the presumed prepared protocol, the method 300 may include implementing a procedure of the plurality of available procedures for the two-phase commit process by bypassing the com m it-request phase of the two- phase commit process for the some participants of the plurality of participants 106, sending prepare requests to remaining participants, other than the some

participants, of the plurality of participants 106 that do not implement the presumed prepared protocol to implement the com m it-request phase of the two-phase commit process for the remaining participants, and implementing the commit phase of the two-phase commit process for all participants of the plurality of participants 106.

[0048] According to examples, in response to the determination that no participant implements the presumed prepared protocol, the method 300 may include implementing a procedure of the plurality of available procedures for the two-phase commit process by sending prepare requests to all participants to implement the comm it-request phase of the two-phase commit process for all participants of the plurality of participants 106, and implementing the commit phase of the two-phase commit process for all participants of the plurality of participants 106.

[0049] Referring to Figure 4, for the method 400, at block 402, the method may include determining, for a transaction 104 that includes a plurality of associated participants 106, whether all participants implement, whether some participants implement, or whether no participant implements a presumed prepared protocol.

[0050] At block 404, in response to a determination that all participants implement, that some participants implement, or that no participant implements the presumed prepared protocol, the method may include respectively implementing a different procedure from a plurality of available procedures for a two-phase commit process that includes a com m it-request phase and a commit phase to commit the transaction.

[0051] According to examples, for the method 400, determining, for the transaction 104 that includes the plurality of associated participants 106, whether all participants implement, whether some participants implement, or whether no participant implements the presumed prepared protocol, may further include analyzing responses to registration requests from each participant of the plurality of participants 106 for joining the transaction 104, and determining, based on the analysis of the responses to the registration requests from each participant of the plurality of participants 106 for joining the transaction 104, whether all participants implement, whether some participants implement, or whether no participant implements the presumed prepared protocol.

[0052] According to examples, in response to the determination that all participants implement the presumed prepared protocol, the method 400 may further include implementing a procedure of the plurality of available procedures for the two-phase commit process by bypassing the com m it-request phase of the two- phase commit process for all participants of the plurality of participants 106, and implementing the commit phase of the two-phase commit process for all

participants of the plurality of participants 106.

[0053] According to examples, in response to the determination that some participants implement the presumed prepared protocol, the method 400 may further include implementing a procedure of the plurality of available procedures for the two-phase commit process by bypassing the com m it-request phase of the two- phase commit process for the some participants of the plurality of participants 106, sending prepare requests to remaining participants, other than the some

participants, of the plurality of participants 106 that do not implement the presumed prepared protocol to implement the com m it-request phase of the two-phase commit process for the remaining participants, and implementing the commit phase of the two-phase commit process for all participants of the plurality of participants 106.

[0054] According to examples, in response to the determination that no participant implements the presumed prepared protocol, the method 400 may further include implementing a procedure of the plurality of available procedures for the two-phase commit process by sending prepare requests to all participants to implement the comm it-request phase of the two-phase commit process for all participants of the plurality of participants 106, and implementing the commit phase of the two-phase commit process for all participants of the plurality of participants 106.

[0055] Referring to Figure 5, for the method 500, at block 502, the method may include determining, for a transaction 104 that includes a plurality of associated participants 106, whether all participants implement, whether some participants implement, or whether no participant implements a presumed prepared protocol.

[0056] At block 504, in response to a determination that all participants implement, that some participants implement, or that no participant implements the presumed prepared protocol, the method may include selecting a procedure from a plurality of available procedures that is to be implemented for a two-phase commit process that includes a comm it-request phase and a commit phase to commit the transaction 104.

[0057] At block 506, the method may include implementing the selected procedure for the two-phase commit process.

[0058] According to examples, in response to the determination that all participants implement the presumed prepared protocol, implementing the selected procedure of the two-phase commit process, may further include bypassing the comm it-request phase of the two-phase commit process for all participants of the plurality of participants 106, and implementing the commit phase of the two-phase commit process for all participants of the plurality of participants 106.

[0059] According to examples, in response to the determination that some participants implement the presumed prepared protocol, the method 500 may further include implementing the selected procedure of the two-phase commit process by bypassing the comm it-request phase of the two-phase commit process for the some participants of the plurality of participants 106, sending prepare requests to remaining participants, other than the some participants, of the plurality of participants 106 that do not implement the presumed prepared protocol to implement the comm it-request phase of the two-phase commit process for the remaining participants, and in response to an authorization to commit from the remaining participants, implementing the commit phase of the two-phase commit process for all participants of the plurality of participants 106.

[0060] According to examples, in response to the determination that no participant implements the presumed prepared protocol, the method 500 may further include implementing the selected procedure of the two-phase commit process by sending prepare requests to all participants to implement the commit- request phase of the two-phase commit process for all participants of the plurality of participants 106, and in response to an authorization to commit from all participants, implementing the commit phase of the two-phase commit process for all participants of the plurality of participants 106.

[0061] Figure 6 shows a computer system 600 that may be used with the examples described herein. The computer system 600 may represent a generic platform that includes components that may be in a server or another computer system. The computer system 600 may be used as a platform for the apparatus 100. The computer system 600 may execute, by a processor (e.g., a single or multiple processors) or other hardware processing circuit, the methods, functions and other processes described herein. These methods, functions and other processes may be embodied as machine readable instructions stored on a computer readable medium, which may be non-transitory, such as hardware storage devices (e.g., RAM, ROM, EPROM, EEPROM, hard drives, and flash memory).

[0062] The computer system 600 may include a processor 602 that may implement or execute machine readable instructions performing some or all of the methods, functions and other processes described herein. Commands and data from the processor 602 may be communicated over a communication bus 604. The computer system may also include a main memory 606, such as a RAM, where the machine readable instructions and data for the processor 602 may reside during runtime, and a secondary data storage 608, which may be nonvolatile and stores machine readable instructions and data. The memory and data storage are examples of computer readable mediums. The memory 606 may include a two-phase commit protocol mixing for distributed transactions

implementation module 620 including machine readable instructions residing in the memory 606 during runtime and executed by the processor 602. The two-phase commit protocol mixing for distributed transactions implementation module 620 may include the modules of the apparatus 100 shown in Figures 1 and 2.

[0063] The computer system 600 may include an I/O device 610, such as a keyboard, a mouse, a display, etc. The computer system may include a network interface 612 for connecting to a network. Other known electronic components may be added or substituted in the computer system.

[0064] What has been described and illustrated herein is an example along with some of its variations. The terms, descriptions and figures used herein are set forth by way of illustration only and are not meant as limitations. Many variations are possible within the spirit and scope of the subject matter, which is intended to be defined by the following claims - and their equivalents - in which all terms are meant in their broadest reasonable sense unless otherwise indicated.