Reliability improvement of distributed transaction processing optimizations based on connection status

A method, computer program product, and system for resolving a potential in-doubt condition of a distributed transaction, is provided. A processor receives a request to commit a transaction for a distributed transaction protocol that includes an applied process, the transaction includes a transfer of a commit decision from a coordinating node to a participating node. The processor checks the service status of the connection to the participating node, and finding the service status of the connection out of service or unavailable, the processor instructs the coordinating node to back-out (rollback) the transaction. Additionally, locality meta-data is used as an indication of reliability of the connection to the participating node, and in response to determining the participating node locality to be a remote network connection, the processor instructs the coordinating node to abort the applied process and send a standard distributed transaction protocol message over unreliable connections.

BACKGROUND OF THE INVENTION

The present invention relates generally to the field of distributed transaction processing, and more particularly to use of connection status techniques to reduce occurrences of in-doubt occurrences of distributed transaction processing.

A distributed transaction is the execution of one or more units of work distributed on different systems. A distributed commit protocol is required to ensure that the effects of a distributed transaction are atomic, that is, either all the effects of the transaction persist or none persist, whether or not failures occur. A well-known commit protocol is the two-phase commit (2PC) protocol. For transaction processing applications such as hotel reservations, airline reservations, stock market transactions, or banking applications, the commit processing takes up a substantial part of the transaction. Therefore, the performance of a commit protocol substantially affects the transaction volume that a system can support.

The “last agent commit process”, is an optimization of the distributed two-phase commit protocol, and is a widely used optimization to improve the performance of commit processing. Last agent commit optimization reduces time-consuming message sending and log writes, between a transaction manager (TM), coordinating the transaction, and a remote resource participant within the distributed processing system. In providing an optimization of the two-phase commit protocol, the last agent commit process removes the prepare phase message for the last participant, and the coordinating participant sends a commit message to the last participant, with all other participants having prepared and confirming a commit vote to proceed. The last participant determines the last vote of whether to proceed with the commit of the transaction process or back-out and roll back the transaction. The last agent commit process creates a potential large period of in-doubt failure between the last remote write and receipt of a commit or back-out (rollback) message.

The period between when a distributed transaction participant has prepared its own recoverable state and voted yes to commit, and the time when it is instructed to perform the commit (or perform a back-out if some failure or no vote was received at some point within the subsequent distributed prepare processing), is known as the “in-doubt” window. Units of work are said to be in-doubt during this time, as they are not yet aware of whether they will need to commit or back out, and access to data involved in the transaction remains locked-out for use by other pending transactions.

SUMMARY

According to one embodiment of the present invention, a method, computer program product, and system for resolving a potential in-doubt condition of a distributed transaction, is provided. The method for preventing an in-doubt condition of a distributed transaction, includes a processor that receives a request to commit a transaction of a distributed transaction protocol including an applied process, the transaction including a coordinating node and a participating node. The processor determines a service status of a connection to the participating node, and in response to determining the service status of the connection to be unavailable, the processor instructing the coordinating node to back-out the transaction.

According to another embodiment of the present invention, the method for resolving a potential in-doubt condition of a distributed transaction, includes the processor that determines a locality of a connection to the participating node, and in response to determining the locality of the connection to be a remote network connection, the processor instructs the coordinating node to abort the applied process of the distributed transaction protocol and alternatively perform a standard distributed transaction protocol process.

DETAILED DESCRIPTION

Embodiments of the present invention, recognize that applied process optimizations of distributed transaction processing protocols, such as last agent commit process optimization of a two phase commit protocol, may result in an in-doubt condition due to failed or unreliable communication connections between two or more transaction system participants. An applied process of a distributed transaction protocol, such as a last agent commit optimization process, is when the coordinator node of a distributed transaction instructs all but one (n-1) of its (n) participant nodes to prepare themselves, and assuming they prepare and each votes yes to a commit, the coordinating participant then sends a message to the final (nth) unit of work to commit. Using and applied process to optimize the distributed transaction avoids a network flow to the last agent participant. In applying the last agent commit optimization process, the coordinator has effectively passed the coordination role of the transaction units of work, to the nthsystem, and the original coordinator now becomes an in-doubt participant in the sync point.

The unit of work in the nthsystem (now the coordinator of the sync point) will either be able to commit to perform the unit of work, or not. If the unit of work can be performed, the nthsystem sends a response message to the original coordinator that it has committed. The response message effectively passes the coordination role back to the unit of work of the original coordinator, which had been in-doubt while it awaited the response. The original coordinator can now commit its own recoverable resource updates, then instruct the n-1 participant units of work to commit themselves (they are all in-doubt with respect to it until this point) Likewise, if the last agent coordinator unit of work had been unable to commit, and had backed-out its changes instead, then the response would have been passed back along with the coordination role to the original coordinating system, which had been in-doubt while it awaited the response. The original coordinator can now back out its own recoverable state changes, then tell the n-1 participant units of work to back out their respective changes (again, they are all in-doubt with respect to it until this point).

The period between when a participant has prepared its own recoverable state and voted yes to commit to a unit of work of a transaction, and the time when the participant is instructed to perform the commit (or perform a back-out if some failure or a “no” vote was received at some point within the distributed prepare processing) is known as the in-doubt window. Units of work are said to be in-doubt during this time, as they are not yet aware of whether they will need to commit or back-out. An in-doubt condition results in a relatively long interruption of processing, and data resources are locked out, unavailable to other transaction processes.

Embodiments of the present invention recognize that interruption or delay of connections between systems participating in a distributed transaction processing environment, producing an in-doubt condition, results in lengthy delays and loss of transactional efficiency intended by applying transaction optimization processes, such as the last agent commit process. Some embodiments recognize that remote participating systems are more likely to experience connection reliability issues, as compared to local connections, due to propagating through additional network connection points and competing with additional communication network traffic.

Some embodiments of the present invention make use of a non-transactional network verification function and meta-data associated with distributed transaction connections, to identify failed or unreliable connections and significantly reduce the likelihood of transactions becoming in-doubt for optimization processes applied to a two-phase commit protocol. A connection status monitoring the service status of a connection to participating nodes of the transaction, is maintained by the transaction process system. Inactive connections are confirmed to prevent the flow of last agent commit messages in the event of failed network connections. Additionally connection locality meta-data is used to determine whether a connection is reliable, and thus whether to apply last agent commit processing or standard two-phase commit processing for the transactions, thus reducing the probability of encountering an in-doubt condition.

Detailed embodiments of the claimed methods, computer program products, and systems, are disclosed herein; however, it is to be understood that the disclosed embodiments are merely illustrative, and other embodiments may be implemented in various forms. In addition, each of the examples given in connection with the various embodiments is intended to be illustrative, and not restrictive. Further, the figures are not necessarily to scale, some features may be exaggerated to show details of particular components. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a representative basis for teaching one skilled in the art to variously employ the methods, computer program products, and systems of the present disclosure.

FIG. 1is a functional block diagram illustrating distributed transaction processing environment100, in accordance with an embodiment of the present invention. Distributed transaction processing environment100includes server computing device110, local resource manager120, remote resource manager130, local database140, and remote database160, all interconnected via network150. Server computing device110is depicted as hosting transaction manager115and connection program300.

Networks150may be, for example, a local area network (LAN), a telecommunications network, a wide area network (WAN), such as the Internet, a virtual local area network (VLAN), or any combination that can include wired, wireless, or optical connections. In general, network150can be any combination of connections and protocols that will support communications between server computing device110, local resource manager120, and remote resource manager130, within distributed computer processing environment100, in accordance with embodiments of the present invention.

Local resource manager120is a resource manager that receives transaction processes from applications to perform units of work of a transaction. Local resource manager120is controlled by transaction manager115, which oversees the execution of application processes by distributing units of work to available resource managers, such as local resource manager120and remote resource manager140. Local resource manager120is depicted as under direct access of transaction manager115, and within a local cluster of server computing device110, as determined by connection locality meta-data, which may include such information as machine specific location, LAN, TCP/IP, sub-network, and cluster communication information.

In some embodiments of the present invention, local resource manager120participates in global transaction processing, in which a transaction protocol may be applied to perform transaction units of work. For example, a two-phase commit protocol may be used by transaction manager (TM)115and local resource120to perform transaction processing, to attain an atomicity in transaction processing. Additionally, an optimization process may be applied to the two-phased commit protocol, such as a last agent commit process, to improve the efficiency and performance of the transactions under a distributed transaction protocol, such as the two-phased commit protocol.

A last agent commit optimization involves the transaction coordinator communicating to all but one of the participating nodes, to prepare to perform a unit of work of a transaction. The transaction coordinator confirms that all but one participant can perform the work, by each participant voting yes to a commit. Confirming the commit by all but one participant, the transaction coordinator communicates a message to the final participant to commit. The coordinator has effectively passed the coordination role to the final participant in another system to determine if the transaction proceeds or is backed out. The unit of work in the other system will determine if it is able to commit or not. If the decision communicated back to the original transaction coordinator is that it has committed, then the commit message is received by the original transaction coordinator, which again assumes the coordinator role, and communicates to the other participants, which had been in-doubt while awaiting the response from the final participant, to commit to their respective units of work of the transaction. Likewise, if the last participant with a unit of work assigned by the transaction manager, had been unable to commit, and had backed out its changes instead, then a back out response would have been passed back along with the coordination role to the original transaction coordinator, which had been in-doubt while it awaited the response. The original coordinator can now back out its own recoverable state changes, then direct the other participants to back out (roll back) the units of work they had performed.

Database140is an example of a resource that includes data that can be acted upon by a resource manager. Database140is accessible by local resource manager120, which is capable of performing transaction units of work on data within database140.

Remote resource manager130is a remote resource manager, located as part of a wide area network relative to server computing device110. Resource manager130is determined to be remote based on connection locality meta-data, which may include such information as machine specific location, LAN, TCP/IP, sub-network, and cluster communication information, for example. Resource manager130receives instructions via a connection with transaction manager115, as a transaction coordinator, which oversees the execution of application processes by distributing units of work to available resource managers, such as resource manager130. In some embodiments in which a last agent commit process optimization is applied to perform a distributed transaction process, remote resource manager130is a remote participant, having a unit of work to perform for a transaction coordinated by transaction manager115.

Database160is an example resource that includes data accessible and managed by resource manager130, which is enlisted by transaction manager115to perform transaction units of work using the data of database160.

Server computing device110may be a desktop computing device, a rack mounted computing device, a blade server, a management server, a mobile computing device, or any other electronic device or computing system capable of performing program instructions, and receiving and sending data. In other embodiments, server computing device110may represent a computing system utilizing multiple computers as a server system, such as in a cloud computing environment. In yet other embodiments, server computing device110may be a laptop computer, a tablet computer, a netbook computer, a personal computer (PC), a desktop computer, a personal digital assistant (PDA), a smart phone, or any programmable electronic device capable of communicating with local resource managers120and remote resource manager130, via network150. In another embodiment, server computing device110may be a computing system utilizing clustered computers and components (e.g., database server computer, application server computers, etc.) that act as a single pool of seamless resources when accessed within distributed computer processing environment100. Server computing device110may include internal and external hardware components, as depicted and described with reference toFIG. 4.

Server computing device110is depicted as including transaction manager115and connection program300. In some embodiments of the present invention, server computing device110performs application process operations that include transactions distributed across a transaction processing environment, such as distributed transaction processing environment100.

In some embodiments of the present invention, transaction manager115is an operational part of a middleware environment residing on server computing device110, and receives workload from client input of running applications. Transaction manager115coordinates the activities of the workload by enlisting resource managers to perform units of work of the transaction workload, such as local resource manager120and remote resource manager130. Transaction manager115sends and receives communication messages with resource managers participating in a distributed transaction protocol, such as a two-phased commit protocol, or an optimization process of a distributed transaction protocol, such as a last agent commit process.

In some embodiments of the present invention, connection program300is an extension of a network management component of a computing system, such as server computing device110. The network management component is used to establish the connection between the nodes participating in the transaction, to handle individual messages that are sent and received over the connection, release the connection when it is no longer needed, and process error conditions that may occur during operations. Connection program300extends the network management component, and uses input regarding the messaging activity of connections as an indication that a connection to a resource manager is still functioning correctly. Connection program300uses meta-data input regarding the locality of a connection as an indicator of the likelihood of reliability.

Connection program300determines the status and potential reliability of communications between transaction manager115and participating resource managers (nodes) of a distributed transaction, to which an optimization, such as a last agent commit process, has been applied. In some embodiments of the present invention, connection program300checks the status of connections to nodes (hereafter, node connections), participating in a distributed transaction, by validating message receipt information of each connection, which is performed by a network management component of the transaction manager host system, such as server computing device110. For example, the network management component (not shown) of server computing device110monitors the receipt of messages from each connection participating in distributed transactions coordinated by transaction manager115. The network management component sets a flag indicating successful receipt of a message from a particular connection.

In some embodiments of the present invention, the network management component of the transaction manager host system sets a flag for each participant from which a message is successfully received within a defined time interval. At the end of the time interval, a separate examination process determines which node connections have been idle, based on the corresponding flag indicating that a message has not been successfully received from the node connection. If node connections are determined to remain idle at the end of a subsequent time interval, the examination process initiates a heartbeat process, which delivers a heartbeat message for the idle node connections, and the examination process resets the flags for all other node connections participating in the distributed transaction, and begins the next time interval. If a reply to the heartbeat message is received, the connection is determined to be operational, and the flag is set indicating the connection as valid and operational for the current time interval. The examination process continues for all node connections participating in the transaction. The examination process does not initiate a heartbeat message for the node connections having connection flags set to indicate the successful receipt of a message within the time interval, indicating a valid and operational connection. This avoids unnecessary message flow and undo interruption of the examination process.

The heartbeat process is invoked to check the validity of a node connection that appears to be in service but has failed to indicate the successful receipt of a message within consecutive time intervals. Invoking the heartbeat process sends a heartbeat message outside of the transaction band, to the node connections determined to be idle. In some embodiments of the present invention, at the end of the time interval, the network management component determines if any node connection of the distributed transaction does not have a flag set indicating that a message has been successfully received within the time interval.

In some embodiments of the present invention, the examination process and the heartbeat process are separate existing modules, operating outside the transaction process, and working in conjunction with the network management component of the host system and connection program300. In other embodiments, the examination process and the heartbeat process may be modules of the network management component of the host system.

The connection status maintained by the network management component of the transaction processing system is used to prevent the flow of last agent commit messages across a failed network connection, and the connection locality meta-data is used to determine whether or not a connection is reliable, based on the locality of the connection. Connection program300determines the information associated with the connection status of participating nodes, as well as the reliability information of participating nodes, based on the connection locality meta-data, and in one embodiment, sends the information to the transaction manager for decision making of whether to proceed with the last agent commit process or revert to the standard two-phase commit process. In another embodiment, connection program300instructs the transaction manager to abort the last agent commit process and alternatively perform a standard two phase commit protocol process, in response to the service status of the connection to the last agent node determined to be unavailable, and in the case of determining the locality of the last commit agent node to be a remote network connection.

FIG. 2is a functional block diagram depicting operational connections200, between two transaction processing systems ofFIG. 1, in accordance with an embodiment of the present invention. Depicted in operational connections200is server computing device110, which includes unit of work210, sync point215, locality meta-data220, connection status225, transaction manager115, and connection program300. Also depicted inFIG. 2, connected via network150, is transaction process connection230, heartbeat message connection235, participating node240, and unit of work245.

Unit of work210is a first component of a transaction to be performed by server computing device110and unit of work245is a second activity of a transaction to be performed by participating node240. In a simplified exemplary embodiment of the present invention performance of unit of work210and unit of work245complete the transaction. Participating node240is a resource manager connected via network150and transaction process connection230to transaction manager115, of server computing device110.

Transaction manager115performs a coordinating role in the distribution of units of work210and245, of the transaction. In some embodiments of the present invention, while performing a two phase commit protocol of a distributed transaction of operational connections200, transaction manager115initiates a sync point for the commit or rollback decision of units of work210and245. A sync point is used to establish atomicity of a transaction, in which all participating nodes commit their respective unit of work, or all participating nodes back-out the transaction updates and return data to a pre-transaction state. In other embodiments, while applying a last agent commit optimization, transaction manager sends a commit message to participating node240and includes information indicating that transaction manager115is prepared to commit or rollback unit of work210, depending on the decision response received from participating node240. In the last agent commit optimization process, transaction manager has transferred the coordinating role to participating node245as the “last agent”, and waits in-doubt for a response from participating node240.

Sync point215is established in the two phase commit protocol by transaction manager115as the coordinating role of the transaction. Sync point215includes sending messages instructing the preparation of performing unit of work210and unit of work245and receiving confirmation “votes” from participating resource managers, for example, participating node240, to commit to performing the unit of work, or to back out and rollback the unit of work to the pre-transaction state.

In some embodiments of the present invention, locality meta-data220includes information regarding the relative location of resource managers connected and communicating with transaction manager115. Locality meta-data220stores node connection information of participating node240, performing unit of work245for the transaction, and node connection information regarding the performance of unit of work210by server computing device110. The information may include, for example, a specific socket used, determining if the resource performing the unit of work shares the same operating system (as is the case of server computing device110and transaction manager115), determining if the node connection is on the same IP sub-network, or determining if the connection is on a different IP address. The information included in locality meta-data220is used to determine if a connection of a participating node in a distributed transaction is local or remote. A local node connection may be within a cluster of interconnected systems within substantially the same location, or may be to a resource manager within the same local area network (LAN). Messages sent to and received from local connections are less likely to experience connection failures related to message-propagating devices, firewalls, and other network events, and thus local connections are considered more reliable than connections that are non-local, or remote. In one embodiment of the present invention, connection program300receives information regarding the locality of a node connection from transaction manager115, and stores the locality information and/or the likely reliability of the connection, in locality meta-data220. In another embodiment, the information regarding the locality of a node connection is stored in locality meta-data220by the network management component of server computing device110(not shown).

Connection status225functions to record if a successful message has been sent to a participating node connection, and a reply or response has been received, within a defined time interval. At the beginning of the defined time interval, the flags for all node connections are set to a default setting of “off”. If a message has been successfully received, the connection is recorded as operational, for example, by setting a flag as “on”. If a message has not been successfully received from the connection, the flag remains at a setting of “off”. Connection status225maintains the status of the connections, also referred to as the service status of the connections of participating nodes, enlisted by transaction manager115, and associated with performing the distributed units of work of the transaction, such as units of work210and245. During a defined time interval, if a message is received from the node connection with participating node240, connection status225changes the default flag setting of “off”, to “on” for the node connection. If, however, during the defined time interval, no message was received from the connection with participating node240, the flag associated with participating node240would remain at the setting of off.

In some embodiments of the present invention, the defined time interval may have lapsed without sending or receiving a message to a participating node, and therefore the status remains at a default setting of off. In order to determine if the connection remains operational, an examination process monitors connection status225, and identifies the connections that have a status of off, at the end of the defined time interval. The examination process initiates a heartbeat process that generates a “heartbeat” message to the participating nodes that have a connection status of off, to test the connection. The successful transmission and response of a heartbeat message may prevent a firewall from releasing network resources associated with an otherwise idle connection. An unsuccessful transmission and response of a heartbeat message, or an unexpected delay in receiving a response to the transmitted heartbeat message, indicates that there may be a potential problem with the connection, and the connection may be unreliable. Heartbeat messages are not sent to connections whose corresponding connection status flag indicates that the connection has received a message within the defined time interval and is valid. In some embodiments of the present invention, the heartbeat message may be repeated, in response to determining a previously unsuccessful heartbeat message.

In some embodiments of the present invention, connection status225resides in system memory and is controlled and accessible by the network management component of server computing device110, the examination process, and connection program300. In other embodiments, connection status225is included as part of a network management component of a participating or coordinating system within distributed transaction processing environment100.

Heartbeat message connection235is a messaging connection between the network management component of server computing device110, working in conjunction with transaction manager115, and participating nodes of the distributed transaction, such as participating node240. Heartbeat connection235is a connection external to the transaction process thread performing units of work210and245over transaction process connection230. A heartbeat process is initiated by an examination process subsequent to determining that a participating node connection has failed to indicate the successful receipt of a message in consecutive time intervals. Heartbeat connection235carries a heartbeat message to nodes determined to be idle, to initiate a response indicating the connection remains valid and operational. Heartbeat connection235carries heartbeat messages only to the node connections indicating an absence of a message received during the defined time interval, to avoid unnecessary flow of messages through the network.

Transaction process connection230is a communication connection between transaction manager115and participating node240. In some embodiments of the present invention, transaction process connection230is a transmission control protocol of the internet protocol suite (TCP/IP) type of connection. Network packets sent over internet protocol (IP) sockets are buffered by the TCP/IP stack in a “send buffer” memory area. The send buffer accommodates several small messages in its memory, such as a commit message from transaction manager115, using a last agent commit process optimization. The socket writer for the send buffer will not be blocked regardless of the state of transaction process connection230, and will transmit messages. If the network encounters a transmission failure, it may not be detected until an acknowledgement packet is not received within a period of time, often in the range of 200 milliseconds. Following the TCP protocol, the message packet will be re-transmitted a number of times until the sending stack reaches a pre-determined limit of retries, and signals a communication error. The re-try period may be in the order of several seconds to minutes, and if the network failure occurs just prior to the sending of a commit message to a participating node as the last agent, there is no reliable way for the sending system to detect the failure. The sending node and other nodes of a multi-node transaction using last agent commit optimization, remain in-doubt due to the undetected connection failure, and continue to hold resources in a lock-out state, anticipating a decision to commit or back out of performing the units of work.

Use of heartbeat messages sent to connections determined to be idle within a defined time interval, enables the detection of failed or delayed connections. The determination of failed or delayed connections, along with the connection reliability information of connection status225, may be used by transaction manager115, to make a decision to defer from using a process optimization, such as last agent commit process, and instead proceed with a standard two phase commit protocol.

FIG. 3illustrates operational steps of connection program300, inserted on a client device within the data processing environment ofFIG. 1, in accordance with an embodiment of the present invention. Connection program300operates in an environment of connected systems potentially utilizing a two phase commit protocol optimization process, such as a last agent commit process. Connection program300receives a request to issue a transaction commit message (step310). The transaction manager receives a request from an application process to commit to a transaction. The architecture of the distributed transaction may have different configurations that include all nodes directly connected to the transaction manager, or a tree structure of nodes, in which the coordinating transaction manager may have nodes that are also transaction managers. The transaction manager issues a “prepare” instruction to all directly connected nodes, except for one node. The node excluded from the prepare instruction is the agent of the last agent commit optimization process. The nodes receiving a prepare instruction determine whether an assigned unit of work can be performed, and return a message vote to commit to the unit of work, or return a back out vote if some condition exists in which the unit of work cannot be performed. If even one of a multitude of nodes returns a vote to back out, all units of work of the transaction are backed out, and results in a rollback of the transaction to a pre-transaction state.

For example, transaction manager115receives a request to issue a commit instruction from an application process. Transaction manager115, operating a distributed transaction protocol utilizing the last agent commit optimization process, sends a prepare message to local resource managers120, but does not send a prepare message to resource manager130. Resource managers120receive the prepare message and unanimously determine to commit to the respectively assigned units of work of the transaction, or if at least one of resource managers120does not vote to commit to perform the respective unit of work of the transaction, the units of work are backed out and a rollback to a pre-transaction state occurs.

Connection program300checks the status of the connections of participating nodes of the transaction (step320). In some embodiments of the present invention, connection program300receives connection status input of participating nodes in the distributed transaction process, indicating if node connections are valid and operational within a defined time interval. If a message has been successfully received from a participating node, within the defined time interval, the connection to the node is determined to be valid. In one embodiment of the present invention, a valid node connection is indicated by an “on” flag corresponding to the node connection. If the node has been idle with regard to messages received and acknowledged, the connection status of an “off” designation, for example, would be indicated and the connection considered to possibly be non-operational.

For example, Connection program300checks connections status225to determine if the connection flag corresponding to resource manager130is on or off. In some embodiments of the present invention, the flag designations may be considered as, “yes” or “no”, “true” or “false”, “active” or “inactive”, or any designation that differentiates between successfully receiving and not receiving a response to a message, from a node, during the defined time interval.

In other embodiments of the present invention, connection program300accesses the status condition of the participating node connections to determine if node connections are valid and operational, as determined within the current defined time interval.

The status of node connections is maintained and updated by an examination process and heartbeat process (input step320A). The information indicating the service status of the connections to the participating nodes, also referred to as the connection status, in some embodiments of the present invention, is maintained by the setting of a flag, corresponding to a particular connection of a node participating in the distributed transaction. In some embodiments, the network management component of the transaction manager host system, updates a flag corresponding to a particular node connection upon the successful receipt of a message from the particular node. An examination process, scheduled at a defined time interval, determines if a flag corresponding to a node connection indicates a failure to successfully receive a message within the defined time interval. The examination process identifies the idle node connection, initiates a heartbeat process that sends a heartbeat message to the idle node connection, and resets the flags for all node connections of the distributed transaction. The examination process continues, and the network management component of the system hosting the transaction manager continues to update flags of corresponding node connections when messages are successfully received. In other embodiments of the present invention, a connection establishment protocol may be used to determine a state of the connection to a participating node.

Connection program300determines whether a node connection is operational within the defined time interval (decision step330), and determining that the node connection is not operational (step330, “NO” branch), connection program300sends a message to the transaction manager to rollback the transaction (step370) In some embodiments of the present invention, determining if the node connection is not operational involves connection program300determining whether the node connection has remained idle for consecutive defined time intervals, which indicates that in a separate process, a heartbeat message has been sent to the idle connection, for example, without successful receipt of a response message. Connection program300determines from the service status of the connection of the participating node that the connection remains idle. The connection status indicates a lost or problematic connection. Sending an instruction to the transaction manager, or sending information to the transaction manager to decide to rollback (back-out) the transaction, enables the transaction manager to notify all other nodes participating in the transaction to rollback their respective units of work. The rollback instruction returns all units of work to their respective pre-transaction state, and releases the lock placed on the resources involved in the transaction. In some embodiments an error message may be generated by the network management component of the coordinating system if the connection remains unresponsive. For example, having confirmed the connection status as idle subsequent to consecutive defined time intervals, in which at least one heartbeat message was sent to the idle connection, connection program300determines that the connection is not operational, and generates a message sent to transaction manager115advising a rollback of all nodes participating in the current transaction.

Having sent a rollback message to the transaction manager, connection program300sends a message to the transaction manager (TM) advising the TM to proceed with a standard two phase commit processing (step380). Connection program300recognizes the non-operational node, which may potentially be designated as a last agent node, and due to the unreliability of the node connection, advises the transaction manager to proceed with a standard two phase commit protocol process, avoiding an in-doubt condition.

For example, transaction manager enlists local resource manager120and remote resource manager130for a distributed process transaction. Connection program300checks the connection status of remote resource130and determines that the connection has been idle for at least two consecutive defined time intervals of the examination process, and sends a message to transaction manager115to rollback the transaction for all nodes participating in the distributed transaction process. Connection program300sends a message to transaction manager115advising a standard two phase commit process to be used for the transaction. Having sent the instruction to proceed with a standard two phase commit process, connection program300ends.

Reverting back to decision step330, connection program300, having determined that a response has been received from the connection to the participating node within the defined time interval (step330, “YES” branch), connection program300checks the locality meta-data of the connection (step340). The locality meta-data includes information indicating whether the connection to the node chosen as the last agent to commit is a local connection or a remote network connection. A local connection may be an integrated component of a system cluster, a system located on a local area network, or a system part of the same sub-network of an IP address, for example. A local connection may not involve network processing components and additional firewalls that may block or delay communication messages, and therefore connection program300considers a local connection as more likely to be a reliable connection if it is determined that the connection status is operational.

A remote network connection may be a connection having a different IP address than that of the system hosting the transaction manager of a distributed transaction. Messages to and from a remote network connection transverse network control devices and routing components that may include the ability to block connection requests or terminate connections inactive for a particular period of time. Messages sent across a remote network connection are considered by connection program300to incur longer delays and be less reliable than local connections. Connection program300accesses the information of locality meta-data220(FIG. 2).

Having accessed locality meta-data information of a participating node selected as the last agent of a last agent commit optimization process, connection program300determines if the connection is local (decision step350). Determining, from the locality meta-data, the connection to the node selected as the last agent to commit, to be a local connection (step350, “YES” branch), connection program300sends a message to the transaction manager (TM) to proceed with using the last agent commit optimization process (step360). For example, connection program300determines from locality meta-data220that the node selected as the last agent is a local connection, on the same sub-network, which indicates to connection program300that the node connection is likely to be reliable. Connection program300advises the transaction manager to proceed with the use of the last agent commit optimization process and continue for the transaction, as the likelihood of an in-doubt condition occurring is low.

Having determined from the locality meta-data, the connection to the node selected as the last agent to commit, to be a remote network connection (step350, “NO” branch), connection program300advises the transaction manager to proceed with standard two phase commit processing (step380), and continue as described above. For example, connection program300has determined that a connection to remote resource manager130, is a remote network connection, by accessing information regarding the connection to remote resource manager130in locality meta-data220. The connection has been selected as the last agent of a last agent commit optimization process by transaction manager115. Connection program300sends instruction to transaction manager115to abort the last agent commit optimization process and proceed with a standard two phase commit process to perform the transaction units of work, due to the information in locality meta-data220indicating remote resource manager130as a remote connection. Having sent the message to transaction manager115, connection program300ends.

Communications unit410, in these examples, provides for communications with other data processing systems or devices, including resources of distributed communication processing environment100. In these examples, communications unit410includes one or more network interface cards. Communications unit410may provide communications through the use of either or both physical and wireless communications links. Connection program300may be downloaded to persistent storage408through communications unit410.

I/O interface(s)412allows for input and output of data with other devices that may be connected to computing device400. For example, I/O interface412may provide a connection to external devices418such as a keyboard, keypad, a touch screen, and/or some other suitable input device. External devices418can also include portable computer-readable storage media such as, for example, thumb drives, portable optical or magnetic disks, and memory cards. Software and data used to practice embodiments of the present invention, e.g., connection program300can be stored on such portable computer-readable storage media and can be loaded onto persistent storage408via I/O interface(s)412. I/O interface(s)412also connect to a display420.