Electrical computers and digital processing systems: multicomput – Computer-to-computer session/connection establishing
Reexamination Certificate
1998-07-31
2001-07-24
Maung, Zarni (Department: 2154)
Electrical computers and digital processing systems: multicomput
Computer-to-computer session/connection establishing
C709S230000, C709S241000
Reexamination Certificate
active
06266698
ABSTRACT:
BACKGROUND OF THE INVENTION
The present invention relates generally to transaction processing systems, and more particularly to techniques for supporting transaction commitment processing for a transaction that is distributed between two transaction management systems using different variations of a commitment processing protocol.
A transaction most often is defined as an explicitly delimited operation, or set of related operations, that change or otherwise modify the content of an information collection (e.g., database or databases) from one consistent state to another. Changes are treated as a single unit in that all changes of a transaction are formed and made permanent (the transaction is “committed”) or none of the changes are made permanent (the transaction is “aborted”). If a failure occurs during the execution of a transaction, resulting in the transaction being aborted, whatever partial changes were made to the collection are undone to leave it in a consistent state.
A transaction processing system typically includes a transaction manager; a collection of subsystems, called resource managers (RMs), which are essentially abstractions of available services, such as database systems; programming languages; user interfaces; application interfaces; and the like. The transaction processing system provides a way to interconnect applications and resource managers while maintaining data integrity and transactional consistency. In this manner, any number of database systems (e.g., DB2, Oracle, Sybase, etc.), any number of programming languages (e.g., C++, Cobol, Fortran, etc.), any number of networks (e.g., OSI, TCP/IP, etc.), any number of presentation managers (e.g., Windows, DOS, etc.), and any number of application generators (e.g., CSP, Pathmaker, Cadre, etc.) are able to interoperate to complete a transaction.
The application process initiating a transaction invokes various services and/or resource managers to perform various operations and tasks necessary to complete the transaction. All services and resource managers invoked to perform operations for the transaction register with a transaction manager, stating that they are joining the transaction. A transaction manager typically provides transaction management functions, such as monitoring the progress of the transaction and coordinating the commit processing and rollback of the transaction, and protects the integrity of user data. When all operations, or work, have completed, the initiating application process notifies the transaction manager of this fact. The transaction manager then initiates an agreement protocol to coordinate commitment processing among all services and resource managers participating in the transaction. In transaction processing the standard agreement protocol is the two-phase commitment (2PC) protocol. A description of the 2PC protocol, as well as a detailed overview of transaction processing, is presented in J. Gray et al.,
Transaction Processing Concepts and Techniques,
Morgan Kauffman, 1993, the contents of which are herein incorporated by reference.
Briefly, in phase one of the 2PC protocol, the transaction manager issues a request prepare signal to each participant (i.e., the transaction manager asks each participating service or resource manager if it believes the operations it performed to be a consistent and complete transformation). If any participant votes no, the commit fails and the transaction is aborted and rolled back; if all participating resource managers vote yes (ready to commit), the transaction is a correct transformation and phase two commences. In phase two of the 2PC protocol, the transaction manager issues a commit request signal informing each participant that the transaction is complete, and records this fact in the transaction's log. After all participants acknowledge the commit request, the transaction manager records this fact and forgets about the transaction.
Two commonly used variations of the 2PC protocol are the presumed abort variation and the presumed nothing variation. Both variations operate identically when there are no failures (e.g., system failure or a connection down at a participant) or when the transaction is not explicitly aborted (e.g., a no vote by any participant).
In the presumed nothing variation of the 2PC protocol, the transaction manager initiates all communications relating to the 2PC protocol, including initiating a recovery process in the event of a failure. Furthermore, when the transaction manager issues a request, such as a prepare request or a commit request or an abort request, the transaction manager must wait for an associated response, such as a prepare ready response or a commit acknowledgment or an abort acknowledgment. In some cases, the presumed nothing variation can be very inefficient. For example, if there is a failure or a no vote and the transaction manager issues an abort request, and if there is a connection down at one of the participants to the transaction, the transaction manager must wait for an abort acknowledgment from that participant. The abort acknowledgment will not be received until at least after the connection is re-established.
In the presumed abort variation of the 2PC protocol, it is not required that the transaction manager initiate all communications relating to the 2PC protocol, or that the transaction manager must wait for a response to a request signal. In particular, both the transaction manager and the participants can initiate a recovery process. For example, in the above example, the transaction manager will clean up and go away without waiting for an abort acknowledgment from any participant, including the participant with the down connection. If, for example, that participant re-establishes a connection at a later time and initiates a recovery process, the transaction manager will check its log record and see that it is not waiting for anything and will assume that the transaction was aborted. It will respond to the querying participant that the transaction has been aborted. In this manner the system performance is not degraded because the transaction manager is not idle (waiting for an abort acknowledgment).
Generally, most transaction processing systems today use the presumed abort variation of the 2PC protocol. However, some systems, including IBM's CICS LU6.2, use the presumed nothing variation of the 2PC protocol. Thus, to support heterogenous transactions with IBM's LU6.2 database, a technique for allowing consistent communications processing, especially after a failure, must be implemented. One way would be to use both protocols in the local transaction management system, one to support the presumed abort variation and one to support the presumed nothing variation. However, this would burden the transaction processing system as it effectively doubles the amount of code needed to be stored and implemented by the transaction manager.
SUMMARY OF THE INVENTION
The present invention provides methods and systems for effectively supporting different variations of a commitment processing protocol in a transaction processing system. In particular, the present invention provides techniques for supporting both the presumed abort and presumed nothing variations of the two-phase commitment (2PC) protocol in a heterogenous transaction processing system.
The techniques of the present invention generally provide an efficient, transparent way to interoperate a system implementing the presumed abort variation of the 2PC protocol with a system implementing the presumed nothing variation. The gateway process that is responsible for exporting a transaction branch to a foreign transaction management system from a system implementing the presumed abort variation records whether the foreign transaction manager is implementing the presumed abort variation or the presumed nothing variation. After a system failure, the gateway process determines which variation is adopted for a specific transaction branch. If the foreign transaction manager is implementing the presumed abort variation,
Carley William J.
Gondi Albert C.
Klein Johannes
Lanka Sitaram V.
Compaq Computer Corporation
Diepenbrock Anthony B.
Maung Zarni
Oppenheimer Wolff & Donnelly LLP
Sherry Leah
LandOfFree
Logging of transaction branch information for implementing... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Logging of transaction branch information for implementing..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Logging of transaction branch information for implementing... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2477462