Browse Prior Art Database

Prevention of Unintentional Orphaning of Indoubt Transaction When an User Uninstalls a Resource From an Application Server

IP.com Disclosure Number: IPCOM000030261D
Original Publication Date: 2004-Aug-03
Included in the Prior Art Database: 2004-Aug-03
Document File: 2 page(s) / 63K

Publishing Venue

IBM

Abstract

This article describes a mechanism by which an application server can prevent the unintentional orphaning of indoubt transactions when a user uninstalls a resource from that server (and that resource currently has indoubt transactions on behalf of that server). Orphaning will occur if the code needed to clean up the indoubt transaction is removed during the uninstall of the resource from the server.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 46% of the total text.

Page 1 of 2

Prevention of Unintentional Orphaning of Indoubt Transaction When an User Uninstalls a Resource From an Application Server

A mechanism is described by which an application server can prevent the unintentional orphaning of indoubt transactions when a user uninstalls a resource from that server (and that resource currently has indoubt transactions on behalf of that server). Orphaning will occur if the code needed to clean up the indoubt transaction is removed during the uninstall of the resource from the server.

     Application Servers allow third party Resources (such as JDBC* Drivers or J2EE* Connector Architecture (JCA) ResourceAdapters) to be installed into the application server to provide connectivity to various backend resources (ex: Relational Databases). This invention involves such resources that support the two phase commit (XA) transaction protocol.

     When such a server crashes in mid transaction, it often leaves indoubt transactions on the backend resource still pending. Under normal operations, the next time the server is started the transaction service of the application server will recover/complete (i.e., either rollback or commit) the pending transactions to the backend resource.

     If the user decides to uninstall the resource from the server without it first having recovered/completed the pending transactions, then there is no way for the application server to ever recover those transactions. It may continue to try unsuccessfully. Eventually, manual intervention will be required to both clean up the transaction log where the transaction service keeps track of the pending transactions, and at the resource manager where the pending transactions will have to be manually completed. Note that there is also an issue that pending transactions can hold locks on certain rows in a relational database such that other applications will be blocked until these pending transactions are completed.

     The general idea behind the solution is to provide interlock mechanisms (using defined API's) between the user (via the systems administration utility) and the transaction service which is part of the application server. The interlock would provide a direct link between the user's attempt to stop or uninstall a resource and the current state of any pending transactions for that resource which the application server's transaction manager was tracking. The following lifecycle activities are included:
1. The uninstalling of a Resource from the application server when the server is NOT running (this can include the scenario that the last time the server was running that it crashed leaving indoubt/pending transactions for the resource which we now are attempting to uninstall). The interlock here would use a well-defined resource identity (resourceID) known both to the application server's systems management and to the transaction service (stored in its recovery log). (Note that since the server is not currently running, some subset of the transaction...