Compaq Computer Corporation, Inc.

Hewlett-packard Development Company, L.p.

Sun Microsystems, Inc.

Bea Systems, Inc.

Compaq Information Technologies Group, L.p.

Albert C Gondi

Sitaram V Lanka

Johannes Klein

William J Carley

Roger J Hansen

Keith B Evans

Sameer Arun Joshi

Charles Stuart Johnson

Thulasiraman Jeyaraman

Pal Takacsi-Nagy

Tony Chun Tung Ng

Yu-Cheung Cheung

Trina R Wisler

Michael Douglas Blow

David J Wisler

John S De Roo

Ramprasad K L Sripada

A transaction management engine, such as a business process management (BPM) engine, can allow an application to define transaction demarcations in order to ensure that portions of a workflow are processed atomically. In one such system, a JMS message is queued to the workflow as part of an existing transaction. If that transaction commits, the queued JMS message ensures that the workflow will be invoked in a new transaction that allows the workflow to perform the next unit of work in the newly initiated transaction. When the unit of work is completed, the workflow queues another JMS message. If this transaction commits, the transaction ensures the unit of work has executed in a transaction. When the workflow is invoked again due to the second JMS message, the workflow can continue its operation in a different transaction.

Systems and methods for transaction chaining

A Registration protocol is used in transaction processing for normal operations. If an error occurs, the system reverts to a Full Broadcast protocol. The Registration Protocol reduces the number of messages that are sent among CPUs in a cluster thereby permitting performance improvements in the system. The Registration Protocol has Begin, DPCheck, PhaseFlush and Phase(lock release) phases just as does the Full Broadcast Protocol, thereby permitting the Full Broadcast protocol to step in at any phase after an error is detected.

Hybrid method for flushing transaction state in a fault-tolerant clustered database

A method for using a Synchronization Interface in a computer system compliant with a CORBA Object Transaction Service or a Java Transaction API (such as Java 2 Platform Enterprise Edition Reference Implementation) to perform internal state clean up in containers associated with a completed transaction. First, a synchronization object is registered for each new transaction in a container with a Transaction Manager. The Transaction Manager detects a completion of the transaction and then invokes an &ldquo;after_completion&rdquo; operation (method) on the synchronization object. This notifies each container involved in the completed transaction to perform internal memory space clean up. Thus, the method uses an existing Synchronization Interface mechanism to perform internal memory state clean up in containers, without adding additional communication mechanisms.

Method for using a transaction service synchronization interface to perform internal state clean up

Methods and systems that provide a resource manager the ability to register with a transaction manager that it needs to be &ldquo;pre-prepared&rdquo; for a transaction. The transaction manager will issue a pre-prepare notification to any resource manager so registered, and will delay phase one of the two-phase commitment (2PC) protocol until all pre-prepare-registered resource managers have responded that they are ready for commitment processing.

Volatile resource manager with pre-prepare notification

A transaction processing system manages an information collection by employing a two-phase transaction commit protocol. Transaction participants are provided a unique identifier for use in communicating with the transaction management facility in a distributed environment. If the participant is lost, a backup participant is created, and provided with the same identifier as the failed participant to carry on with the transaction in place of the failed participant.

Method and apparatus for handling failures of resource managers in a clustered environment

Incorporation of a collateral process as a participant in a transaction is made possible by a method and system in accordance with the present invention. Typically, after the transaction is initiated, the collateral process is called and then is registered as a participant,in the transaction. A prepare signal is sent to each registered collateral process when end stage of the transaction is reached. Then, a ready signal is received from the collateral process if the collateral process is completed successfully; and an abort signal is received from the collateral process if the collateral process does not complete successfully or a violation is detected. If a ready signal is received, a commit record is written to a log, and a commit signal is sent to each registered collateral process. In response to the commit signal, a forgotten signal is received from each registered collateral process.

Incorporating collateral and concurrent activity in a data processing transaction

A protocol for a transaction involving two homogeneous or two heterogeneous computing systems involves starting a transaction on one of the two systems, sending a request for participation in the transaction to an application resident on the other of the two systems, together with an identification and address of the transaction. Upon receipt of the request, the application will initiate a subordinate transaction through a resident (subordinate) transaction manager. The subordinate transaction manager will notify the Beginner transaction manager and at the same time cause the application to start work on the request. Later, the subordinate transaction, through the subordinate transaction manager participates in a two-phase commit protocol that concludes the transaction to ensure that all changes effected by the transaction are done, or none are done, i.e., the transaction is aborted.

Method and apparatus for conducting a transaction between homogeneous and/or heterogeneous transaction processing systems using asynchronous pull of a transaction transfer

Systems and Methods for identifying in the gateway processes or application processes whether an imported transaction is a loop-back transaction, and if so performing work for the imported transaction under the parent transaction. Upon receiving a work request from a remote transaction processing system, an endpoint identifier included as part of the work request is analyzed to determine whether the work request is associated with a parent transaction initiated at the local transaction processing system. If the endpoint identifier indicates that the work request is associated with a transaction initiated in the local transaction processing system, a global transaction identifier included as part of the work request is analyzed to determine the identity of the parent transaction. If the work request includes a remote TIP URL, the application process that receives the request is configured to analyze the global transaction identifier and determine the identity of the parent transaction. If the remote transaction processing system sends a push request, the gateway process that receives the request is configured to analyze the global transaction identifier and determine the identity of the parent transaction. Work is thereafter performed according to the work request under the parent transaction such that a new transaction is not initiated.

Systems and methods for the detection of a loop-back of a transaction

Systems and methods for supporting and maintaining a distributed global map of transaction identifiers at the gateway processes using a hashing algorithm configured on each application process to access the global maps. A global map of transaction identifiers that associates global transaction identifiers with remote local transaction identifiers is maintained at each gateway process. When an application process performing work for a particular transaction desires to export the transaction to a remote node, a hashing function configured on the application process is applied to the global transaction identifier associated with the particular transaction. Application of the hashing function to the global transaction identifier identifies one of the gateway processes. The global transaction identifier is stored to the global map associated with that gateway process. When the remote transaction manager associated with the remote node responds with a local transaction identifier for a local transaction initiated at the remote node, the local transaction identifier is stored to the identified gateway's global map in association with the global transaction identifier. Each application process is configured with the same hashing function so that the same gateway process will always be identified given a particular global transaction identifier. If the same or another application process desires to export to a remote node a transaction that has already been exported, the hashing function on that application process identifies the same gateway through which the transaction was originally exported.

Process of maintaining a distributed map of transaction identifiers and using hashing to access these maps

Systems and methods for ensuring that two different subordinate transactions will not be created at any given transaction processing node for the same parent transaction. Upon receiving a work request from a remote transaction processing system, the local transaction manager creates a local subordinate transaction associated with the parent transaction. A local transaction identifier that identifies the local subordinate transaction is also created. The local identifier includes an indicator, such as a one-bit flag, which identifies the local subordinate transaction as an imported transaction. The global identifier for the parent transaction is stored to a map in association with the transaction identifier of the new local subordinate transaction. If a work request associated with an imported transaction is sent to a remote transaction processing system, the global transaction identifier of the parent transaction is retrieved from the map and included in the work request so that the receiving system will know that the work request is associated with the parent transaction. In this manner, the receiving system will know not to start a new subordinate transaction on behalf of the parent transaction if a transaction subordinate to the parent transaction has already been started on that system.

Detection of an imported transaction for finding the global transaction identifier

A transaction processing system, including multiple processor units communicatively interconnected, manages information collection by employing a distributed transaction management facility to track and make consistent changes. When each transaction is started, a data structure is created that maintains information concerning the transaction. Included in the data structure is the identity of all processor units having resources involved in the transaction. Should a processor unit fail, and the transaction management facility is notified of that failure, the data structures of all pending transactions will be examined to see if the failed processor unit had a resource that was a participant in the corresponding transaction. If so, the transaction management facility can then make a decision as to whether or not to abort the transaction.

Fault-tolerant transaction processing in a distributed system using explicit resource information for fault determination

Methods and systems for interoperating a transaction processing system implementing the presumed abort variation of the two-phase commit (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 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, the transaction manager from which the transaction branch originated communicates with the foreign transaction manager through the gateway process in accordance with the presumed abort variation. If the foreign transaction manager is implementing the presumed nothing variation, the gateway process takes charge of driving abort processing in a manner transparent to the originating transaction manager.

Growing community of inventors

Santa Clara, CA, United States of America

Albert C Gondi