WO2016169048A1

WO2016169048A1 - Transaction management and committing

Info

Publication number: WO2016169048A1
Application number: PCT/CN2015/077391
Authority: WO
Inventors: Sean L BROEDER; Shang-Sheng Tung; John Deroo; Ming Liu
Original assignee: Hewlett Packard Enterprise Development Lp
Priority date: 2015-04-24
Filing date: 2015-04-24
Publication date: 2016-10-27

Abstract

Examples associated with transaction management and committing are disclosed. One example includes transmitting data manipulation language (DML) instructions associated with a transaction to a set of resource managers. The DML instructions may be sent by a transaction manager. The DML instructions describe modifications to be made by the resource managers to resources controlled by respective resource managers. Acknowledgements are received from the resource managers in response to the DML instructions. The acknowledgments indicate when modifications have passed conflict resolution for respective resources and when the modifications have been made durable in the respective resources. Commit instructions are transmitted to the resource managers when acknowledgements the DML instructions have been received.

Description

TRANSACTION MANAGEMENT AND COMMITTING

In high concurrency environments, some systems (e.g., databases) having high transaction rates employ a two-phase commit protocol to ensure that changes are committed to the environment, while maintaining certain guarantees regarding the system (e.g., the ACID properties) . To complete a transaction, a transaction manager pushes data manipulation instructions (e.g., insert, update, delete) associated with the transaction to resource managers that control and/or manipulate various resources. The resource managers perform actions associated with the transaction and eventually the transaction manager begins a process to commit the actions.

The two-phase commit protocol has two-phases, a voting phase and a commit phase. During the voting phase, a transaction manager asks resource managers involved in a transaction whether to commit or abort the transaction. Still during the voting phase, the resource managers perform conflict detection for the transaction, and prepare to commit the transaction (e.g., by making changes durable in logs and/or in respective resources) before voting whether to commit the transaction. If, for example, conflict detection fails on a resource manager or some other error occurs, that resource manager will vote to abort. When all resource managers vote to commit, the transaction manager tells the resource managers to commit the transaction, beginning the commit phase, causing the resource managers to complete operations associated with the transaction. If any resource manager votes to abort, the transaction manager forces all resource managers to roll back actions associated with the transactions.

BRIEF DESCRIPTION OF THE DRAWINGS

The present application may be more fully appreciated in connection with the following detailed description taken in conjunction with the accompanying drawings, in which like reference characters refer to like parts throughout, and in which:

FIG. 1 illustrates an example environment, in which example systems, and methods, and equivalents, may operate.

FIG. 2 illustrates a flowchart of example operations associated with transaction management and committing.

FIG. 3 illustrates another flowchart of example operations associated with transaction management and committing.

FIG. 4 illustrates another flowchart of example operations associated with transaction management and committing.

FIG. 5 illustrates an example system associated with transaction management and committing.

FIG. 6 illustrates an example computing device in which example systems, and methods, and equivalents, may operate.

DETAILED DESCRIPTION

Systems, methods, and equivalents associated with transaction management and committing are described. Transaction management and committing may be achieved by performing conflict detection as data manipulation language (DML) instructions are received by resource managers. Additionally, write ahead logging for actions associated with the transaction may also be performed as DML instructions are received as opposed to during a voting phase of a two-phase commit protocol. After each of these steps is completed for a given DML instruction, the respective resource manager will inform the transaction manager that actions associated with that DML instruction are completed, at which point the transaction manager may provide another DML instruction to that resource manager.

Once all DML instructions have been acknowledged, the transaction manager may skip the voting phase as conflict detection and making actions durable to resources have already been completed for each DML instruction. Consequently, the transaction manager may skip the explicit voting phase and proceed straight to sending a commit instruction to resource managers to cause the resource managers to commit the actions associated with the transaction to the respective resources. The resource managers may also perform cleanup operations (e.g., freeing memory, releasing locks) associated with the transaction upon receiving the commit instructions.

This technique is sometimes described herein as a “presumed prepared” two-phase commit protocol. As the transaction manager receives acknowledgements regarding DML instructions, the transaction manager may presume those DML instructions have passed conflict detection and are prepared for committing. Once the transaction manager is able to presume each DML instruction associated with a transaction is prepared, the transaction manager may cause the transaction to be committed. If the transaction manager receives an error signal, (e.g., due to failure of a resource manager, due to a conflict) , the transaction manager may signal to the resource managers that the transaction should be aborted, causing the resource managers to roll back actions made durable, and reverting log entries as appropriate. As will be explained herein, conflict detection, which is often performed by presumed abort protocols during the voting phase, has been rolled into the phase where DML instructions are executed.

The claims, specification, and figures sometimes refer to a transaction manager. In some system architectures, separation of responsibility for transaction managers, applications, and resource managers may not be maintained. Consequently, in these cases, for example, applications themselves may serve as transaction managers that send DML and commit instructions to resource managers. Consequently, as used herein, a transaction manager may refer to whatever process is directing operations of resource managers, and may be dependent on architecture level decisions of whatever system is performing the examples disclosed herein.

Figure 1 illustrates an example environment 100 in which example systems and methods, and equivalents, may operate. It should be appreciated that the items depicted in figure 1 are illustrative examples and many different features and implementations are possible.

Figure 1 illustrates an example environment 100. Environment 100 includes a transaction manager 110. Transaction manager 110 may be in communication with several resource managers 120. Resource manager 120 may be responsible for managing various resources 130. Transaction manager 110, resource managers 120, and resources 130 may operate in numerous configurations. In some examples, resources 130 may be distinct resources. In other examples, resources 130 may be mirrored resources to facilitate distributed access to resources 130. In some examples, transaction manager 110, resource managers 120, and resources 130 may operate within a single system or computer. In this example, transaction manager 110 and resource managers 120 may be separate processes operating on the system or computer. In various examples, resource managers 120 may operate on different cores of a multi-core processor, and/or threading may be used to prioritize which processes are operating at any given time (e.g., due to one process waiting for a memory access to complete) . Resources may be, for example, various data stores, services, and so forth associated with environment 100.

In other examples, transaction manger 110, resource managers 120, and/or resources 130 may operate on distributed systems. As illustrated, resource managers 120 and resources operate in various combinations. For example, a single resource manager 122 controls a single resource 132, a single resource manager 124 controls multiple resources 134, multiple resource managers 126 control a single resource 132, and multiple resource managers 128 control multiple resources 138. Depending on the design of environment 100, many configurations for controlling resources may be appropriate to facilitate provision of services associated with environment 100.

Over time, many tasks associated with these services may be requested of environment 100. In some examples, the tasks may take the form of transactions that are directed by transaction manager 110. Transactions may be, for example, simple data requests associated with a resource 130, or a complex series of changes to several resources and/or analysis based on the changes. To facilitate performing the transactions, transaction manager 110 may identify which resources 130 are implicated by a given transaction and direct resource managers 120 to take the actions on resources 130. This architecture may be appropriate to distribute actions taken on resources to different processes, computers, systems, and so forth. In another example, the architecture may facilitate providing certain service guarantees by making duplicate copies of data.

In various examples, transaction manager 110 may seek to operate in a manner that ensures reliable processing of transactions. There are four properties that, when implemented together, are considered to guarantee that transactions are processed reliably: atomicity, consistency, isolation, and durability (the ACID properties) . Atomicity requires that transactions are all or nothing–if any portion of a transaction fails, the entire transaction must be reverted. Consistency ensures that systems always maintain valid states as defined by, for example, various constraints, rules, and so forth placed on the system. Isolation refers to the idea that concurrently run transactions will produce the same database result as transactions run serially. Durability ensures that a committed transaction remains committed, even if the system subsequently failures.

The two-phase commit process, in combination with conflict checking that occurs either as transactions are processed via locking techniques, or during the two-phase commit process, is one process for ensuring that transactions maintain the four ACID properties. For example, conflict checking may prevent a later initiated transaction that modifies data already being accessed by a not yet committed earlier initiated transaction from initiating at least until the earlier initiated transaction commits, thereby maintaining the isolation property. Similarly, the voting phase facilitates maintaining the atomicity property by either committing an entire transaction or rolling the entire transaction back during the commit phase.

Some two-phase commit protocols that employ a voting phase are referred to as “presumed abort” protocols. One distinction between presumed abort protocols and presumed prepared protocols occurs when a resource manager 120 recovers from a failure. Under a presumed abort protocol, a resource manager 120 that reviews log records for a transaction and finds records without a corresponding “prepared” log record, will presume that these records were aborted. If transactions are discovered with “prepared” log records, the resource manager 120 will take an appropriate action after receiving an abort instruction or a commit instruction from transaction manager 110. Consequently, if any resource manager 120 fails (e.g., crashes) at any point before the voting phase for a transaction completes, that entire transaction must be rolled back due to uncertainty regarding whether log entries associated with the transaction were made durable prior to the failure. Further, when recovering from a failure (e.g., crash) , any transaction found in a log without a corresponding commit record or prepared record may be presumed aborted and ignored when replaying actions to recover a state prior to the failure.

Additionally, in systems that operate using presumed abort two-phase commit protocols, committing transactions may be resource intensive because much of the transactional overhead for presumed abort protocols occurs during the voting phase and the commit phase. This is because many actions, including, for example, conflict checking, making changes durable, and so forth, may occur during the voting phase before a resource manager 120 can vote to commit a transaction. Further, in environments with many participants (e.g., resource managers, resources) , a substantial amount of message traffic may be generated by the initiation of the voting phase, making it so that there is a relatively high marginal cost for additional remote procedures.

By way of illustration, after receiving an instruction initiating a voting phase for a transaction using a presumed abort two-phase commit protocol, a resource manager 120 has to ensure that the changes are durable to the resource (e.g., by flushing logs and other changes not yet made durable) . If locking techniques are used, the resource manager 120 may proceed directly to making the changes durable. However, if a non-locking technique is used, the resource manager 120 must perform conflict checking during the voting phase prior to making the modifications to the resource durable. This finally puts the resource manager 120 in a “prepared” state at which point the resource manager 120 can vote to commit.

Under a presumed prepared protocol, except for brief periods where a resource manager 120 is in the process of performing actions on a resource (e.g., due to being in the process of executing a DML instruction) , transaction manager 110 may assume that all resource managers 120 are in a perpetually “prepared state” , and may proceed immediately to the commit phase, skipping the voting phase of the two-phase commit entirely. This is because resource managers 120 vote with acknowledgements to the DML instructions as the DML instructions are completed. Consequently, when a resource manager 120 recovers from a failure, the resource manager 120 does not necessarily need to take any action regarding transactions having “prepared” log entries without a commit entry, as it is possible that transaction manager 110 did not even notice that the resource manager 120 failed.

In one example of a presumed prepared protocol, processing of a transaction begins when transaction manager 110 receives a signal describing the transaction. Transaction manager 110 will then identify what actions various resource managers 120 will need to take to execute the transaction based on resources implicated by the transaction. Transaction manager 110 will then formulate these actions into DML instructions to be executed by the resource manager 120, and begin transmitting the instructions to resource managers 120.

Upon receiving the DML instructions, resource managers 120 will begin by identifying which resources 130 are implicated by the DML instructions and, in some examples, which portions (e.g., rows, pages) of resources 130 are implicated by the DML instructions. At this point the resource managers 120 may perform conflict detection on resources 130 and/or the portions of resources 130. Conflict detection may take various forms, and may ensure that a resource manager 120 performing an action on a resource does not interfere with an already in progress transaction being executed on a resource.

One form of conflict detection involves locking resources and/or portions of resources being manipulated by transactions. In this case, flags are set on resources 130 or on portions of resources 130 that inform resource managers 120 that a resource or portion of a resource is already in use by another transaction. When a resource manager 120 performs conflict detection, if a lock is detected on a resource or portion of a resource implicated by a DML instruction, the resource manager 120 may, for example, wait for the lock to be removed, abort the transaction, and so forth. Alternatively, lockless conflict detection may be implemented by comparing modifications associated with the current transactions against modifications of other transactions to see if a conflict will exist between the different modifications. If a conflict is detected, a resource manager 120 may wait until the conflicting modification is committed before proceeding with executing the DML instruction, may abort the transaction, and so forth.

Once no conflicts are detected, and/or once the resource manager 120 has waited for any conflicts to clear (e.g., due to committing of conflicting actions, due to removal of locks) , the resource manager 120 may begin to execute the DML instructions in accordance with the transaction. First, write ahead logging is performed to ensure that changes made to the resource appear in a log before the change is actually made to the resource. This is unlike transactions executed using a presumed abort protocol, where log entries may be cached for some time. A presumed prepared protocol, on the other hand, will make log entries durable as DML instructions are executed because logging an action to make it durable is a condition of acknowledging that a DML instruction has been completed. This ensures that if a failure occurs, changes to the resource appear in the log and can be repeated if appropriate, as opposed to unlogged changes having occurred to the resource.

Once write ahead logging has been performed the DML instruction may finally be executed. As an optimization, many systems may temporarily hold actual changes to a resource in, for example, a cache for a variety of reasons. For example, a portion of the resource is regularly changed, repeatedly loading and storing that portion of the resource may be an inefficient use of, bandwidth, memory, and so forth. Further, if a transaction is aborted, no changes need to be remade to the actual resource if those changes were held in the cache but not yet written to the resource. Eventually, the changes may need to be flushed to the resource, but once the logging of the changes have occurred, the changes are effectively made durable because the changes will be re-made to the resource after a crash, assuming the changes are not subsequently revoked (e.g., due to a transaction aborting) .

After conflict detection, write ahead logging, and execution of the DML instruction, the resource manager 120 may now acknowledge to transaction manager 110 that the DML instruction has been executed. This ensures that, except for the time between transaction manager 110 transmitting the DML instruction to the resource manager 120 and receiving the acknowledgement, transaction manager 110 can treat the resource manager 120 as in a state that is “prepared” to commit, hence the terminology “presumed prepared” . If transaction manager 110 has more DML instructions that need to be completed by that resource manager 120, transaction manager 110 may then transmit the next DML instruction to the resource manager 120, repeating the process until transaction manager 110 has sent all DML instructions associated with the transaction to appropriate resource managers 120, and has received acknowledgements for each of the DML instructions.

If execution of the DML instruction by the resource manager 120 fails for whatever reason (e.g., conflict detection fails, an error occurs logging or executing the instruction) , instead of an acknowledgement, the resource manager 120 may transmit a message to transaction manager 110 that effectively votes to abort the transaction. This may cause transaction manager 110 to send signals to other resource managers 120 involved with the transaction, causing them to roll back actions associated with the transaction and perform other steps associated with aborting a transaction.

Once all DML instructions have been completed by the various resource managers 120 associated with the transaction, transaction manager 110 may begin the commit process for the transaction by transmitting a commit instruction to each of the resource managers 120. This skips the voting phase, because the resource managers 120 have already voted to commit the transaction each time they acknowledged successful execution of a DML instruction. Upon receiving the commit instructions, the resource managers 120 may commit the changes already made durable over the course of the transaction by appending an appropriate entry to the log and flushing the entry to durable storage. The resource managers 120 may also perform any appropriate cleanup process by, for example, releasing locks, freeing memory associated with the transaction, and so forth.

As described above, the presumed prepared protocol avoids the need to transmit messages during a voting phase. As storage mechanisms become increasingly fast (e.g., due to non-volatile memory, in memory databases, solid state drives, systems where persistence is achieved by data replication) , the cost of making data durable may be increasingly reduced. Consequently, flushing data to durable memory (e.g., hard disk, non-volatile memory) may become less time consuming than transmitting and acknowledging the DML instructions.

Further, on systems where high concurrency causes instructions sent to resource managers 120 to fill up an instruction queue, creating additional threads for performing conflict detection and data flushing may further increase the queue and delay execution of other transactions . Consequently, it may be less expensive to make changes durable as the changes are performed rather than creating additional resource strain on processing by using a two-phase commit protocol with a voting phase.

Additionally, in the event that a resource manager 120 operating using a presumed prepared two-phase commit protocol fails (e.g., crashes) in the middle of a transaction, it may not be necessary to abort the transaction. At the outset, transaction manager 110 may not even notice the failure unless transaction manager 110 transmits an instruction (e.g., a DML instruction, a commit instruction) to the failed resource manager 120 while the failed resource manager 120 is down. If the failure is detected, transaction manager 110 has no more DML instructions that need to be completed by the failed resource manager 120, and that resource manager 120 failed in a “prepared” state (e.g., it had acknowledged completion of the most recently received DML instruction) , transaction manager 110 can instruct other resource managers 120 to commit the transaction, and instruct the failed resource manager 120 to commit the transaction when it comes back online. Consequently, a presumed prepared two-phase commit protocol may enhance transaction resiliency under certain circumstances.

It is appreciated that, in the following description, numerous specific details are set forth to provide a thorough understanding of the examples. However, it is appreciated that the examples may be practiced without limitation to these specific details. In other instances, methods and structures may not be described in detail to avoid unnecessarily obscuring the description of the examples. Also, the examples may be used in combination with each other.

“Module” , as used herein, includes but is not limited to hardware, firmware, software stored on a computer-readable medium or in execution on a machine, and/or combinations of each to perform a function (s) or an action (s) , and/or to cause a function or action from another module, method, and/or system. A module may include a software controlled microprocessor, a discrete module, an analog circuit, a digital circuit, a programmed module device, a memory device containing instructions, and so on. Modules may include one or more gates, combinations of gates, or other circuit components. Where multiple logical modules are described, it may be possible to incorporate the multiple logical modules into one physical module. Similarly, where a single logical module is described, it may be possible to distribute that single logical module between multiple physical modules.

Figure 2 illustrates an example method 200 associated with transaction management and committing. Method 200 may be embodied on a non-transitory computer-readable medium storing computer-executable instructions. The instructions, when executed by a computer, may cause the computer to perform method 200. In other examples, method 200 may exist within logic gates and/or RAM of an application specific integrated circuit (ASIC) .

Method 200 includes transmitting data manipulation (DML) instructions at 210. The DML instructions may be transmitted by a transaction manager. The DML instructions may be transmitted to a set of resource managers. In one example, the resource managers may be processes operating on the same system as the transaction manager. This scenario may occur when the transaction manager and resource managers are operating on cores of a multi-core system, when multiple processes are operating on a single system, and so forth. In another example, the resource managers may be distributed processes operating on systems remote to the transaction manager. The DML instructions may be associated with a transaction. The DML instructions may describe modifications to be made by the resource managers to resources controlled by respective resource managers. For example, the DML instructions may include, insert instructions, update instructions, delete instructions, and so forth.

Method 200 also includes receiving acknowledgments at 220. The acknowledgements may be received by the transaction manager from the resource managers. The acknowledgements may be received in response to the DML instructions. Each acknowledgement may indicate that modifications from a DML instruction have a) passed conflict resolution for respective resources, and b) have been made durable in the respective resources. In one example, conflict resolution may be passed when a resource implicated by a DML instruction is unheld. An unheld resource may allow a respective resource manager to obtain a lock on the resource to ensure error-free completion of the DML instruction. In another example, conflict resolution may be passed when a resource manager ensures that a resource implicated by a DML instruction is not being actively modified by other concurrent transactions. In another example, conflict resolution may be passed when resources implicated by a DML instruction are distinct from resources associated with other transactions being performed by respective resource managers.

A DML instruction being made durable may mean, for example, that log entries associated with the DML instruction have been created and flushed from the cache to a durable storage media (e.g., hard disc, non-volatile memory) . In other examples, making the DML instruction may include executing the DML instruction, and making changes associated with executing the instruction durable to a storage media.

Method 200 also includes transmitting commit instructions at 230. The commit instructions may be transmitted to the resource managers. The commit instructions may be transmitted when acknowledgements for the DML instructions have been received.

Figure 3 illustrates a method 300 associated with transaction management and committing. Method 300 includes receiving a series of instruction signals at 310. The series of instruction signals may be received in a resource manager. The resource manager may provide a service associated with a resource. The series of instruction signals may be received from a transaction manager. The series of instruction signals may be associated with a transaction. The instruction signals may describe actions to take with respect to the resource.

For each instruction signal, a series of actions may be taken by the resource manager. Consequently, the resource manager may determine at 320 whether there are further instructions signals. If there is another pending instruction signal, the resource manager may proceed to performing conflict detection on an action associated with the instruction signal at 330. Conflict detection may ensure that the action does not modify portions of the resource being operated on by other actions being performed by the resource manager. In some examples, conflict detection may also ensure that the action does not modify portions of the resource being operated on by other actions being performed by other resource managers.

Method 300 also includes logging the action at 350. This may involve generating a log entry describing the action and flushing the log entry to durable storage. Logging the action at 350 prior to performing the action may ensure that, if a failure occurs prior to the action being made durable, the action can be repeated if it is not completed prior to the failure.

Method 300 also includes acknowledging to the transaction manager that the action has been logged at 370. Acknowledging the action has logged may involve transmitting a signal to the transaction manager to inform the transaction manager that actions associated with the instruction signal have been performed.

If, at action 320, it is determined there is not another pending instruction signal, the resource manager may proceed to receiving a commit instruction for the transaction from the transaction manager at 380. In some examples, receiving the commit instruction at 380 may indicate that there are not further instructions to be performed by the resource manager. After receiving the commit instruction at 380, the resource manager may log that the transaction has been committed at 390.

Figure 4 illustrates a method 400 associated with transaction management and committing. Method 400 includes several actions similar to those described above with reference to method 300 (figure 3) . For example, method 400 includes receiving a series of instruction signals at 410, determining if there is another instruction signal at 420, performing conflict detection on an action associated with an instruction signal at 430, logging the action at 450, acknowledging the action has been logged at 470, receiving a commit instruction at 480, and logging the commit instruction at 490.

Method 400 also includes waiting for other actions being performed by the resource manager to be committed at 440. Waiting for other actions may be preferable to returning an error to the transaction manager which might cause the transaction to abort. Consequently, waiting for the other actions to commit at 440 before logging the action at 450, and acknowledging the action at 470 may make transactions complete more reliably than if transactions abort the instant a conflict is detected. As above, in a scenario where conflict detection is also performed based on actions being performed by other resource managers, it may also be appropriate to wait for these actions to commit if a conflict is detected.

Method 400 also includes cleaning up assets associated with the transaction at 499. Cleaning up assets may include, for example, releasing locks associated with the transaction, freeing memory associated with the transaction, notifying a waiting transaction that a resource is available for use, and so forth.

Figure 5 illustrates a system 500 associated with transaction management and committing. System 500 includes a transaction manager 510. Transaction manager 510 may perform transactions on resources 530. Resources 530 may be controlled by a set of resource managers 520. As illustrated in this example, resource manager 522 manages a data store (e.g., database) 532, resource manager 524 manages resource 534, and resource manager 526 manages resource 536. In other examples some resource managers 520 may manage multiple resources 530, and/or some resources 530 may be managed by multiple resource managers 520. Transaction manager 510 may perform the transactions by transmitting instructions associated with the transactions to resource managers 520. Subsequently, transaction manager 510 may receive instruction completion acknowledgements from resource managers 520. Once an instruction completion acknowledgment has been received for each instruction, transaction manager 530 may transmit commit instructions to resource managers 520.

In one example, transaction manager 510 may receive an error from a resource manager 520 regarding a transaction. In this scenario, transaction manager 510 may transmit an abort signal to other resource managers 520. The abort signal may cause the other resource managers 520 to roll back actions associated with the transaction.

System 500 also includes the set of resource managers 520. Resource managers 520 may perform actions on resources 530 based on the instructions received from transaction manager 510. Performing an action may include performing conflict detection on the actions, logging the actions, making the actions durable, and providing instruction completion acknowledgements to transaction manager 510 as actions are completed. Resource managers 520 may also commit the actions upon receiving a commit instruction from the transaction manager.

In various scenarios, resource managers 520 may fail for various reasons. Upon recovering from a failure, a resource manager may transmit a status query regarding a transaction to transaction manager 510. Based on a response to the status query received from transaction manager 510, the resource manager may selectively commit or roll back actions associated with the transaction.

Figure 6 illustrates an example computing device in which example systems and methods, and equivalents, may operate. The example computing device may be a computer 600 that includes a processor 610 and a memory 620 connected by a bus 630. The computer 600 includes a transaction management and committing module 640. Transaction management and committing module 640 may perform, alone or in combination, various functions described above with reference to the example systems, methods, apparatuses, and so forth. In different examples, transaction management and committing module 640 may be implemented as a non-transitory computer-readable medium storing computer-executable instructions, in hardware, software, firmware, an application specific integrated circuit, and/or combinations thereof.

The instructions may also be presented to computer 600 as data 650 and/or process 660 that are temporarily stored in memory 620 and then executed by processor 610. The processor 610 may be a variety of various processors including dual microprocessor and other multi-processor architectures. Memory 620 may include non-volatile memory (e.g., read only memory) and/or volatile memory (e.g., random access memory) . Memory 620 may also be, for example, a magnetic disk drive, a solid state disk drive, a floppy disk drive, a tape drive, a flash memory card, an optical disk, and so on. Thus, memory 620 may store process 660 and/or data 650. Computer 600 may also be associated with other devices including other computers, peripherals, and so forth in numerous configurations (not shown) .

It is appreciated that the previous description of the disclosed examples is provided to enable any person skilled in the art to make or use the present disclosure. Various modifications to these examples will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other examples without departing from the spirit or scope of the disclosure. Thus, the present disclosure is not intended to be limited to the examples shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

A method, comprising:

transmitting, by a transaction manager, data manipulation language (DML) instructions associated with a transaction to a set of resource managers, where the DML instructions describe modifications to be made by the resource managers to resources controlled by respective resource managers；

receiving acknowledgements from the resource managers in response to the DML instructions, where the acknowledgments indicate when modifications have passed conflict resolution for respective resources and when the modifications have been made durable in the respective resources；

transmitting commit instructions to the resource managers when acknowledgments for the DML instructions have been received.
The method of claim 1, where the DML instructions include one or more of, insert instructions, update instructions, and delete instructions.
The method of claim 1, where the resource managers are processes operating on the same system as the transaction manager.
The method of claim 1, where the resource managers are distributed processes operating on systems remote to the transaction manager.
The method of claim 1, where conflict resolution is passed when a lock on a resource implicated by a DML instruction is unheld, allowing a respective resource manager to obtain a lock on the resource to ensure error-free completion of the DML instruction.
The method of claim 1, where conflict resolution is passed when a resource manager ensures that a resource implicated by a DML instruction is not being actively modified by other concurrent transactions.
The method of claim 1, where conflict resolution is passed when resources implicated by a DML are distinct from resources associated with other transactions being performed by respective resource managers.
A method, comprising:

receiving, in a resource manager that provides a service associated with a resource, from a transaction manager, a series of instruction signals associated with a transaction, the instruction signals describing actions to take with respect to the resource；

for each instruction signal:

performing conflict detection on an action associated with the instruction signal to ensure that the action does not modify portions of the resource being operated on by other actions being performed by the resource manager；

logging the action；

acknowledging to the transaction manager that the action has been logged； and

receiving a commit instruction for the transaction from the transaction manager； and

logging that the transaction has been committed.
The method of claim 7, comprising: cleaning up assets associated with the transaction.
The method of claim 8, where cleaning up assets includes one or more of, releasing locks associated with the transaction, freeing memory associated with the transaction, and notifying a waiting transaction that a resource is available for use.
The method of claim 7, comprising: waiting for other actions being performed by the resource manager to be committed.
A system, comprising:

a transaction manager to perform transactions on resources controlled by a set of resource managers by: transmitting instructions associated with the transactions to the resource managers, receiving instruction completion acknowledgements from the resource managers, and transmitting commit instructions to the resource managers once an instruction completion acknowledgment has been received for each instruction；

the set of resource managers to perform actions on the resources based on the instructions by: performing conflict detection on the actions； logging the actions； and providing instruction completion acknowledgements to the transaction manager as actions are completed, and to commit the actions upon receiving a commit instruction from the transaction manager.
The system of claim 12, where the resources are databases.
The system of claim 12, where the transaction manager, upon receiving an error from a resource manager regarding a transaction, transmits an abort signal to other resource managers to cause the other resource managers to roll back actions associated with the transaction.
The system of claim 12, where a resource manager, upon recovering from a failure, transmits a status query regarding a transaction to the transaction manager, and selectively commits or rolls back actions associated with the transaction based on a response to the status query received from the transaction manager.