Abstract: Systems and methods are provided for supporting transaction recovery based on a strict ordering of two-phase commit calls. At least one resource manager in a mid-tier transactional environment can be designated as the “determiner resource,” in order to support eliminating mid-tier transaction logs (TLOG) in processing a two-phase transaction. A transaction manager can prepare all other resource managers in the mid-tier transactional system before the determiner resource. Furthermore, the transaction manager can rely on the list of outstanding transactions to be committed that is provided by the determiner resource for recovering the transaction. The transaction manager can commit an in-doubt transaction returned from a resource manager that matches the list of in-doubt transactions returned from the determiner resource. Otherwise, the transaction manager can roll back the in-doubt transaction.

Abstract: Systems and methods are provided for supporting transaction recovery based on inline delegation of transaction logs to a database. The system can retrieve transaction recovery information of a transaction from a persistence store, wherein the transaction recovery information is persisted on a resource manager that is associated with the persistence store during a prepare phase. Furthermore, the system can retrieve one or more in-doubt transactions from one or more participating resource managers of the transaction. Then, the system can determine whether to commit or roll back the one or more in-doubt transactions by matching the one or more in-doubt transactions to the transaction recovery information.

Abstract: A system and method for providing dynamic transaction optimizations, such as dynamic XA transaction optimizations. In accordance with an embodiment, the system enables monitoring of transactional behavior in an application during runtime, in order to provide a feedback loop. The application/transaction information in the feedback loop can be analyzed by a transaction manager to determine an indication as to whether a particular optimization, such as an isSameRM optimization, will provide a benefit or not. The optimization can then be applied accordingly. In accordance with various embodiments, such determination can be made transparently, so that its enablement is not detectable to, e.g., an end-application, or a system administrator, even though the distribution and type of XA calls may be detected through system monitoring. The feature can be used to improve the performance of transaction processing in a transaction-based system.

Abstract: A system and method for providing dynamic transaction optimizations, such as dynamic XA transaction optimizations. In accordance with an embodiment, the system enables monitoring of transactional behavior in an application during runtime, in order to provide a feedback loop. The application/transaction information in the feedback loop can be analyzed by a transaction manager to determine an indication as to whether a particular optimization, such as an isSameRM optimization, will provide a benefit or not. The optimization can then be applied accordingly. In accordance with various embodiments, such determination can be made transparently, so that its enablement is not detectable to, e.g., an end-application, or a system administrator, even though the distribution and type of XA calls may be detected through system monitoring. The feature can be used to improve the performance of transaction processing in a transaction-based system.

Abstract: A transaction processing system provides the capability to use one two-phase commit engine over multiple protocols and products, while being able to vary the log presumptions according to the requirements of each protocol and product. The transaction processing system comprises a coordinator operable to receive a commit or abort request from a transaction and to perform a two-phase commit protocol on behalf of the transaction and a recovery presumption mechanism operable to perform a recovery process on the transaction upon recovery of the transaction processing system from a failure.

Abstract: Recovery of inflowed transactions are provided by any instance in a cluster, along with peer recovery of transactions in a cluster, and administrative functionality related to these aspects. A method of managing transaction processing comprises performing transaction processing using a first process, wherein the first process logs the transaction processing that it performs, detecting failure of the first process, wherein the transaction logs of the first process are locked, taking ownership of the locked transaction logs of the first process at a second process, unlocking the locked transaction logs of the first process for use by the second process, and recovering at least one transaction using the transaction logs.

Abstract: A method, system, and computer program product for processing a transaction between a client and an application server asynchronously in a distributed transaction processing environment having at least one transaction queue manager. An application request is received from a client to initiate a transaction. The request is placed in a transaction request queue by the transaction queue manager. The request is processed at the application server asynchronously relative to the receipt of the request. A response to the request is determined, and the response is placed in a transaction response queue for retrieval by the client.

Abstract: A transaction system that allows for analysis and administration at the global transaction participant level is disclosed.

Abstract: A framework by which arbitrary routines may be executed in reaction to specific events for analysis and testing, while avoiding the need to manipulate the actual code being monitored. A method for performing functional failure testing of a software-based system comprises monitoring execution of target software for occurrence of a specified event, in response to detecting occurrence of the specified event, performing an action to cause or simulate a failure of the target software or of software or hardware that operatively interacts with the target software, and monitoring the target software for a response to the performed action.

Abstract: A method, system, and computer program product provides advanced and fine-grained transaction administration features, along with interoperability between transactional software architectures and business entities. A method of administering recovering transactions comprises the steps of operating a transaction processing system, and attempting recovery of a plurality of transactions in the transaction processing system after a failure of the transaction processing system by determining a recovery action to be taken for each of the plurality of transactions individually.

Abstract: A system and methods are provided for allowing a transaction based on arbitrary atomic transaction models initiated in a web services environment to be imported into a J2EE application server environment. An extensible mechanism is provided to bridge from the web services environment into XA and execute a web services operation in the context of the bridged transaction. A resource adapter deployed in the application server receives a SOAP request and converts it into a SOAPMessage, and determines whether it comprises a transaction request. The SOAPMessage is inflowed into the application server as Work, and is routed to a SOAP processing engine (instead of packaging the request for delivery to an application component). The SOAP engine processes the request within the context of the transaction imported from the web services environment. A SOAPMessage response may be returned to the resource adapter and serialized to the web services environment.

Abstract: A method, system, and computer program product for processing a transaction between a client and an application server asynchronously in a distributed transaction processing environment having at least one transaction queue manager. An application request is received from a client to initiate a transaction. The request is placed in a transaction request queue by the transaction queue manager. The request is processed at the application server asynchronously relative to the receipt of the request. A response to the request is determined, and the response is placed in a transaction response queue for retrieval by the client.

Abstract: A transaction system that allows for analysis and administration at the global transaction participant level is disclosed.

Abstract: A method and apparatus for reducing logging overhead in systems where at least some of the participants conform to the two-phase commit protocol is provided. Transaction logging is eliminated at the transaction manager. The fault recovery mechanism is altered to obtain transaction status from participating resource managers logs, instead of relying on transaction manager logs.

Abstract: Recovery of inflowed transactions are provided by any instance in a cluster, along with peer recovery of transactions in a cluster, and administrative functionality related to these aspects. A method of managing transaction processing comprises performing transaction processing using a first process, wherein the first process logs the transaction processing that it performs, detecting failure of the first process, wherein the transaction logs of the first process are locked, taking ownership of the locked transaction logs of the first process at a second process, unlocking the locked transaction logs of the first process for use by the second process, and recovering at least one transaction using the transaction logs.

Abstract: A method, system, and computer program product provides advanced and fine-grained transaction administration features, along with interoperability between transactional software architectures and business entities. A method of administering recovering transactions comprises the steps of operating a transaction processing system, and attempting recovery of a plurality of transactions in the transaction processing system after a failure of the transaction processing system by determining a recovery action to be taken for each of the plurality of transactions individually.

Abstract: A system and methods are provided for allowing a transaction based on arbitrary atomic transaction models initiated in a web services environment to be imported into a J2EE application server environment. An extensible mechanism is provided to bridge from the web services environment into XA and execute a web services operation in the context of the bridged transaction. A resource adapter deployed in the application server receives a SOAP request and converts it into a SOAPMessage, and determines whether it comprises a transaction request. The SOAPMessage is inflowed into the application server as Work, and is routed to a SOAP processing engine (instead of packaging the request for delivery to an application component). The SOAP engine processes the request within the context of the transaction imported from the web services environment. A SOAPMessage response may be returned to the resource adapter and serialized to the web services environment.

Abstract: A transaction processing system provides the capability to use one two-phase commit engine over multiple protocols and products, while being able to vary the log presumptions according to the requirements of each protocol and product. The transaction processing system comprises a coordinator operable to receive a commit or abort request from a transaction and to perform a two-phase commit protocol on behalf of the transaction and a recovery presumption mechanism operable to perform a recovery process on the transaction upon recovery of the transaction processing system from a failure.

Abstract: A framework by which arbitrary routines may be executed in reaction to specific events for analysis and testing, while avoiding the need to manipulate the actual code being monitored. A method for performing functional failure testing of a software-based system comprises monitoring execution of target software for occurrence of a specified event, in response to detecting occurrence of the specified event, performing an action to cause or simulate a failure of the target software or of software or hardware that operatively interacts with the target software, and monitoring the target software for a response to the performed action.

Abstract: A software tool is disclosed comprising conversion logic for automatically porting a web application from a first application server format to a second application server format, and a user interface for receiving user input, wherein the conversion logic automatically executes according to the user input.