Local transaction management

[0002] The present invention relates broadly to a transaction management between software entities in a computer environment. Specifically, the present invention enables an application server to manage resource manager local transactions.

[0003] An Enterprise Information System (EIS) provides the information infrastructure for an enterprise utilizing a computer system having a client server arrangement. An EIS offers a set of services to its clients. These services are exposed to clients as local and/or remote interfaces. Examples of an EIS include enterprise resource planning (ERP) systems, transaction processing (TP) systems, and database systems. There are two aspects of an EIS: the system level services and an application specific interface.

[0004] A connector is a standard extension mechanism for application servers to provide connectivity to an EIS. A connector is specific to an EIS and consists of a resource adapter and application development tools for EIS connectivity. A resource adapter plugs into an application server through the server's support for system level contracts. As used herein, a contract refers to the respective responsibilities two or more software entities have when interacting with each other. The Java 2 Platform, Enterprise Edition (J2EE) is the platform of choice for EISs. Two of the relevant parts are an EIS vendor-provided resource adapter and an application server that allows the resource adapter to plug in. An EIS resource provides EIS-specific functionality to its clients.

[0005] A resource manager manages a set of shared EIS resources. A client requests access to a resource manager to use its managed resources. A transactional resource manager can participate in transactions that are externally controlled and coordinated by a transaction manager. A resource manager is typically in a different address space or on a different machine from the client that accesses it. A connection enables an application client to connect to a resource manager, perform transactions, and access services provided by that resource manager. A connection can be either transactional or non-transactional.

[0006] An application component can be a server-side component, such as an Enterprise Java Bean (EJB), Java server page (JSP), or a servlet that is deployed, managed, and executed on an application server. It can also be a component executed on the web-client tier but made available to the web-client by an application server. Examples of the latter type of application component include a Java applet, or a DHTML page.

[0007] A container is a part of an application server that provides deployment and runtime support for application components. It provides an integrated view of the services provided by the underlying application server for the application components. Containers can run on existing systems; for example, web servers for the web containers, application servers, transaction processing monitors, and database systems for EJB containers. This enables enterprises to leverage both the advantages of their existing systems and those of J2EE. Enterprises can write (or rewrite) new applications using J2EE capabilities and can also encapsulate parts of existing applications in EJB or JSP. Enterprise applications access functions and data associated with applications running on EISs. Application servers extend their containers and support connectivity to heterogeneous EISs. Enterprise tools and Enterprise Application Integration (EAI) vendors add value by providing tools and frameworks to simplify the EIS integration task. J2EE provides containers for client applications, web components based on servlets, JSPs and Enterprise JavaBeans (EJB) components.

[0008] FIG. 1A shows a high level block diagram of components involved in transaction management as performed in prior client server computer systems 101 implementing an EIS 101. An application component 102 is deployed in a container 104 provided by an application server 106. The application component 102 performs transactional access to multiple resource managers 108-1, 108-2, . . . , 108-n, where n can be any number. The application server uses a transaction manager 110 to manage transactions across multiple resource managers 108. Each resource manager utilizes a corresponding resource adapter 112. Transaction manager 110 comprises a set of software modules that coordinates transactions across multiple resource managers. It also provides additional low-level services that enable transactional context to be propagated across systems. The services provided by transaction manager 110 are not visible directly to the application components 102.

[0009] In FIG. B, an application client process 114 invokes EJB X 116 in a typical transaction. EJB X 116 accesses transaction programs managed by transaction processing system 118. EJB X 116 calls EJB Y 120 that accesses an ERP system 122. EJB X 116 and EJB Y 120 access the transaction processing system 118 and ERP system 122 using respective client access APIs for the two systems. The application server 106 enlists the connections to both systems (obtained from their respective resource adapters) as part of the transaction. When the transaction commits, transaction manager 110 perform a two phase commit protocol across the two resource managers 108. This ensures that the read/write access to resources managed by both transaction processing system 118 and ERP system 122 is either all committed, or all rolled back.

[0010] The resource managers 108 can support two types of transactions. Transactions controlled and coordinated by the transaction manager 110 external to the resource manager 108 are referred to as JTA transactions or XA transactions. The second type of transaction is managed internal to the resource manager 108. The coordination of such transactions involves no external transaction managers. As used herein, such transactions are referred to as local transactions. If a single resource manager instance participates in a transaction, the application server 106 uses the transaction manager 110 to manage the transaction. However, using the transaction manager 110 has a significant performance overhead. This overhead incurs a significant processing cost in typical EISs that perform a large number of transactions. Thus, there is a need for a solution that avoids the overhead of using an XA transaction with a single resource manager.

[0011] The present invention defines a transaction management contract between an application server and a resource adapter and its underlying resource manager that allows an application server to utilize local transactions on a resource manager and avoid the overhead of an external transaction manager. As used herein, contract refers to responsibilities two individual software components have with respect to interacting with each other. The transaction management contract incorporates two aspects that apply to different types of transactions. The first aspect provides an application level transaction contract between a transaction manager and a resource manager based on javax.transaction.xa.XAResource of the J2EE specification. The J2EE specification is incorporated herein by reference in its entirety.

[0012] The second aspect is local transaction management contract. These contracts enable application server to provide the infrastructure and runtime environment for transaction management. An application component relies on this transaction infrastructure to support its component level transaction model.

[0013] FIGS. 1A and 1B show the functional components involved in transaction processing in prior client-server computer systems;

[0014] FIG. 2 illustrates in block diagram form the hardware utilized in a transaction management system according to the present invention;

[0015] FIG. 3 illustrates in block diagram form the functional components of the present invention that allow an application server to manage local transactions on a resource manager;

[0016] FIG. 4 illustrates an application server managing a local transaction on a resource manager;

[0017] FIG. 5 illustrates an optimization of the application server managing local transactions on a resource manager

[0018] FIG. 6 illustrates a sequence of steps executed to perform local transaction management for a container-managed transaction demarcation; and

[0019] FIG. 7 illustrates a sequence of steps executed to perform local transaction management for a component-managed transaction demarcation.

[0020] Directing attention to the drawings, FIG. 2 is a high level block diagram of the hardware typically used in an embodiment of the present invention. Computer 150 incorporates a processor 152 utilizing a central processing unit (CPU) and supporting integrated circuitry. Memory 154 may include RAM and NVRAM such as flash memory, to facilitate storage of software modules executed by processor 152, such as transaction management system 200 (FIG. 3). Also included in computer 150 are keyboard 158, pointing device 160, and monitor 162, which allow a user to interact with transaction management system 200 during execution. Mass storage devices such as disk drive 164 and CD ROM 166 may also be in computer 150 to provide storage for transaction management system 200 and associated files. Computer 150 may communicate with other computers via modem 168 and telephone line 170 to allow transaction management system 200 to be operated remotely, or utilize files stored at different locations. Other media may also be used in place of modem 168 and telephone line 170, such as a direct connection or high speed data line. The components described above may be operatively connected by a communications bus 172.

[0021] Local Transaction Management Contract

[0022] The present invention defines a local transaction contract between application server and resource manager that enables the application server to manage resource manager local transactions, as shown in FIG. 4. The local transaction management contract has two aspects. In the first aspect, the application server uses the javax.resource.spi.LocalTransaction interface to manage local transactions transparently to an application component and to perform transaction optimizations. The second aspect of the contract relates to notifications for local transaction related events. If a resource adapter supports a local transaction demarcation API, for example, the javax.resource.cci.LocalTransaction for Common Client Interface, the resource adapter needs to notify application server of the events related to the local transaction, such as transaction begin, commit, and rollback.

[0023] Local Transaction Interface

[0024] The javax.resource.spi.LocalTransaction interface defines the contract between an application server and resource adapter for the local transaction management. If a resource adapter supports the LocalTransaction interface, then the application server can choose to perform local transaction optimization (uses local transaction instead of a JTA transaction for a single resource manager case) for applications which allow use of this optimization.

[0025] ConnectionEventListener Interface

[0026] An application server implements the javax.resource.spi.ConnectionEventListener interface. It registers this listener instance with the ManagedConnection instance by using ManagedConnection.addConnectionEventListener method. The following code example specifies the ConnectionEventListener interface related to the local transaction management contract:

[0027] The ManagedConnection instance notifies its registered listeners for transaction related events by calling methods—localTransactionStarted, localTransactionCommitted, localTransactionRolledback.

[0028] The ConnectionEvent class defines the following types of event notifications related to local transaction management contract:

[0029] LOCAL_TRANSACTION_STARTED: notifies that a local transaction was started using the ManagedConnection instance.

[0030] LOCAL_TRANSACTION_COMMITTED: notifies that a local transaction was committed using the ManagedConnection instance.

[0031] LOCAL_TRANSACTION_ROLLEDBACK: notifies that a local transaction was rolled back using the ManagedConnection instance.

[0032] Local Transaction Optimization

[0033] An application component provider has to indicate to the container using a deployment descriptor whether local transaction optimization can be used or not by the container. This deployment hint is required because the container cannot unilaterally make a decision on whether or not to perform local transaction optimization. For example, when the container starts a transaction, it cannot find out (without a hint through the deployment descriptor) about the number of resource managers that will participate in this transaction. If a deployment descriptor indicates that a container can use local transaction optimization than the container can, but is not required to, use local transaction instead of JTA transaction when managing transactions.

[0034] Connection Sharing

[0035] A connection typically maintains state specific to a client-security context, data/function access related data structures (example—query results). An application may want to share this connection state across multiple component instances or across methods on a single component instance. The connection sharing is very typical in non component based applications that just use a single connection under the same client context to access an EIS. When an application is developed using the J2EE component model, there is an issue related to how a connection is acquired and shared to achieve the functionality similar to that of an equivalent non-component based application. The connector architecture enables an application server to allow a connection and its state to be shared across multiple methods on a single component instance or across component instances. The connection sharing mechanism is transparent to the application components. To enable connection sharing, the application component provider/deployer has to provide a deployment hint to the container. This deployment hint indicates which methods and component instances will share a connection. The mechanism by which the connector architecture supports connection sharing is illustrated in the following scenarios. An application server can also support a mechanism to share connection state other than the local transaction association (for example, result set or prepared statements for database access) across methods or component instances. This mechanism is similar to the mechanism described in the following scenarios.

[0036] Scenario: Container-Managed Transaction Demarcation

[0037] In FIG. 5, the stateful session beans A 216 and B 220 have container-managed transaction demarcation with the transaction attribute set to Required. Both EJBs A 216 and B 220 access a single EIS resource manager as part of their business logic. Based on the deployment hint from the application component provider, the application server 206 has decided to perform local transaction optimization for method invocations on both EJBs 216 and 220. FIG. 6 illustrates the flow of steps executed in this scenario. Beginning at step 300 the client invokes a method on EJB A 216 with no transaction context. In its method implementation, the EJB A 216 acquires a connection to the EIS instance. At step 302, during the acquiring of the connection, the container starts a local transaction by invoking begin method on the javax.resource.spi.LocalTransaction instance. The local transaction is tied to the ManagedConnection instance that is associated with the connection handle (as acquired by the component in the previous step). At step 304, after start of the local transaction, any recoverable unit of work performed by the EJB A 216 on the EIS resource manager (using the acquired connection) is automatically included under the local transaction context. At step 306, the EJB A 216 now invokes a method on the EJB B 220. In this scenario, EJB A 216 does not call close on the connection handle before invoking method on EJB B 220 instance. An application server 206 is required to ensure that the connection sharing mechanism is equally applicable if the EJB A 216 were to close connection handle before calling EJB B 220. Continuing to step 308, in the invoked method, the EJB B 220 makes a request to acquire a connection to the same EIS resource manager. At step 310, the application server 206 returns a connection handle using the same ManagedConnection instance that was used for handling the connection request from the EJB A 216 instance. At step 312, the application server 206 retains the association of the ManagedConnection instance with the local transaction context across the method invocation from EJB A 216 to EJB B 220. This means that any unit of work that EJB B instance will perform on the EIS resource manager 208 using its acquired connection handle) will be automatically included as part of the current local transaction. The connection state (for example, any open cursors) can also be retained across method invocations when the local transaction association for a physical connection is being shared. At step 314, before method on EJB B 220 instance completes, the EJB B 220 calls close on the connection handle. The application server 206 should not initiate any cleanup of the physical connection at this time as there is still an uncompleted local transaction associated with the shared physical connection. In this scenario, the cleanup of a physical connection refers to dissociation of the local transaction context from the ManagedConnection instance. At step 316, upon regaining control, EJB A 216 can use the same connection handle (provided EJB A 216 had not called close on the connection handle) to access EIS resources; all recoverable unit of work on the EIS resource manager 208 will be included in the existing local transaction context. If EJB A 216 closes the connection handle before calling EJB B 220, and then reacquires the connection handle (on getting the control back), the application server 206 should ensure that the local transaction context stays associated with the shared connection. At step 318, the EJB A 216 eventually calls close on its connection handle. The application server 206 gets a connection close event notification. At step 320, since there is an uncompleted local transaction associated with the underlying physical connection, the application server 206 does not initiate a cleanup of the ManagedConnection on receiving the connection close event notification. The application server 206 still has to go through completion process for the local transaction. At step 322, when the business method invocation on EJB A 216 instance completes successfully without any application error, the container starts the completion protocol for the local transaction. The container calls LocalTransaction.commit method to commit the transaction. At step 324, after the local transaction is completed, the application server 206 initiates a cleanup (now there is no active local transaction) of the physical connection instance by calling ManagedConnection.cleanup method. The application server should initiate cleanup of the ManagedConnection instance in the case where EJB A 216 does not call close on the connection handle before returning. The application server 206 identifies this need for cleanup of ManagedConnection based on the scope of connection sharing defined through the deployment descriptor. At step 326, upon invocation of the cleanup method, the ManagedConnection instance does a cleanup of its local transaction related state and resets itself to a default state. At step 328, the application server 206 puts the physical connection back in to the pool for handling subsequent connection requests.

[0038] Connection Scenario:

[0039] In a Component-Managed Transaction Demarcation scenario, both stateful session beans A 216 and B 220 do bean-managed transaction demarcation using JTA UserTransaction interface. Both EJBs A 216 and B 220 access a single EIS resource manager 208 as part of their business logic. Based on the deployment hint from the application component provider, the application server 206 has decided to perform local transaction optimization for the method invocations across EJBs A 216 and B 220. FIG. 7 illustrates the following sequence of steps in this scenario. At step 350, the client invokes a method on EJB A 216 with no transaction context. Since EJB A 216 will manage transactions itself, the container dispatches the method invocation to the EJB A 216 instance without any associated transaction context. At step 352, in its method implementation, the EJB A 216 instance acquires a connection to the EIS and then begins a transaction by invoking UserTransaction.begin method. Application server 206 should also support the case where a component invokes UserTransaction.begin method before acquiring a connection. At step 354, when EJBA 216 instance invokes UserTransaction.begin method, the container starts a local transaction on the physical connection (ManagedConnection instance) by calling LocalTransaction.begin method. To support this, the application server 206 provides an implementation of UserTransaction interface. The UserTransaction implementation delegates transaction demarcation calls to LocalTransaction instance if local transaction optimization is being used; in other cases, UserTransaction implementation delegates to the transaction manager 210. The container also starts managing the association of the local transaction context with the ManagedConnection instance. Any recoverable unit of work performed by the EJB A 216 instance on the EIS resource manager 208 is now automatically included under the local transaction context. At step 356, the EJB A 216 invokes a method on the EJB B 220 instance. EJB A 216 does not call close on the connection handle before invoking method on EJB B 220. At step 358, the application server 206 retains the association of the connection with the local transaction context across this method invocation from EJB A 216 to EJB B 220. This means that any unit of work that EJB B 220 instance will perform on the EIS resource manager 208 (in the invoked method) will be automatically included as part of the current local transaction. At step 360, the EJB B 220 instance makes a request to acquire a connection to the same EIS resource manager 208. The application server 206 returns a connection handle using the same ManagedConnection instance (which represents the physical connection) that was used for handling the connection request from EJB A 216 instance. The application server 206 retains the local transaction association with this ManagedConnection instance. At step 362, before the method on EJB B 220 instance completes, the EJB B 220 calls close on the connection handle. The application server 206 does not initiate any cleanup on the physical connection at this time as there is an uncompleted local transaction associated with the physical connection. At step 364, upon getting the control back, EJB A 216 can use the previously acquired connection handle (provided EJB A 216 had not previously called close on the connection handle) to access EIS resources; any recoverable unit of work on the EIS resource manager 208 will be included in the existing local transaction context. At step 366, the EJB A 216 instance calls UserTransaction.commit method to initiate commit of the transaction. The container handles this commit request successfully by calling the method LocalTransaction.commit to commit the local transaction. At step 368, EJB A 216 calls close on the connection handle. The application server 206 gets a connection close event notification. Since there is no local transaction associated with the ManagedConnection instance, the application server 206 initiates a cleanup of the ManagedConnection instance by calling ManagedConnection cleanup method. At step 370, if the EJB A 216 instance had called close on the connection handle before invoking UserTransaction.commit in the same method, then the application server 206 will not initiate any cleanup of the ManagedConnection instance on this connection close. The application server 206 initiates cleanup of the ManagedConnection only when the associated local transaction gets completed on UserTransaction.commit invocation. At step 372, the application server 206 identifies the need for initiating cleanup of ManagedConnection instance based on the scope of connection sharing defined using the deployment descriptor. If cleanup of ManagedConnection is needed, the application server should initiate cleanup even in the case where EJB A 216 has not called close on the connection handle before returning. At step 374, upon the cleanup method invocation, the ManagedConnection instance does a cleanup of its local transaction related state and resets itself to a default state. At step 376, the application server 206 puts the physical connection back in to the pool for handling subsequent connection requests.

[0040] Transaction Management Contract Requirements

[0041] A resource adapter can be classified as follows based on the level of transaction support:

[0042] 1) Level NO_TRANSACTION: The resource adapter does not support either resource manager local or JTA transactions.

[0043] It does not implement either XAResource or LocalTransaction interfaces.

[0044] 2) Level LOCAL_TRANSACTION: The resource adapter supports resource manager local transactions by implementing the LocalTransaction interface.

[0045] 3) Level XA_TRANSACTION: The resource adapter supports both resource manager local and JTA transactions by implementing LocalTransaction and XAResource interfaces respectively. The above levels reflect the major steps of transaction support that a resource adapter needs to make in order to allow external transaction coordination. Depending on its transactional capabilities and requirements of its underlying EIS, a resource adapter can choose to support any one of the above transaction support levels.

[0046] An application server may be used to support resource adapters with all three levels of transaction support —NO_TRANSACTION, LOCAL_TRANSACTION, XA_TRANSACTION. The following are the requirements for an application server 206 for the transaction management contract:

[0047] 1) application server 206 is required to support a transaction manager 210 that manages transactions using the JTA XAResource based contract. The application server 206 is required to use the LocalTransaction interface based contract to manage local transactions for a resource manager. The application server 206 is required to use deployment descriptor mechanism to discover the transactional capabilities of a resource adapter. Additionally, application server 206 can, but is not required to, support local transaction optimization, as well as support a connection sharing mechanism.

[0048] The following description describes how an application server 206 uses the event notifications from the resource adapter to manage local transactions and to restrict illegal transaction demarcations by an application component. In these scenarios, an application component starts a local transaction using an application level transaction demarcation interface (example: javax.resource.cci.LocalTransaction as defined in the CCI) supported by the resource adapter. The resource adapter in its implementation of the transaction demarcation interface sends event notifications related to the local transaction—namely, local transaction begin, commit and rollback. The application server gets notified of these local transaction related events through the ConnectionEventListener mechanism.

[0049] Local Transaction Cleanup

[0050] The following is a set of scenarios that illustrate the function of the present invention as related to the cleanup of local transactions.

[0051] Scenario 1: A stateless session bean with bean-managed transaction demarcation starts a local transaction in a method invocation. It returns from the business method without completing the local transaction. The application server implements the ConnectionEventListener interface. The resource adapter notifies the application server with LOCAL_TRANSACTION_STARTED event when the local transaction is started by the session bean instance. When the session bean instance returns from the method invocation without completing the local transaction, the application server detects this uncompleted local transaction as it has not received any matching LOCAL_TRANSACTION_COMMITTED or LOCAL_TRAN-SACTION_ROLLEDBACK event from the resource adapter.

[0052] On detecting a uncompleted local transaction, the application server terminates the stateless session bean instance and throws an exception to the client.

[0053] Scenario 2: The container terminates a component instance—for example, because of some system exception in a method invocation. On termination of a component instance, the application server cleans up all ManagedConnection instances being used by this component instance. The cleanup of a connection involves resetting all local transaction and client specific state. This state is maintained internal to the ManagedConnection instance. The application server initiates a cleanup of a ManagedConnection instance by calling ManagedConnection.cleanup. After the cleanup, the application server puts this connection back in to the pool to serve future allocation requests.

[0054] Transaction Interleaving

[0055] The application server is required to ensure that transactions are interleaved serially on a connection. The application server uses the connection event listener mechanism (specified through interfaces ConnectionEventListener and ConnectionEvent) to flag illegal cases of transaction demarcation. The application server is required to implement the Connection-EventListener interface to support this scenario.

[0056] A scenario for component-managed transaction demarcation is also included. Scenario: An EJB component (with bean managed transaction demarcation) starts a local transaction using the application-level transaction demarcation interface (example: javax.resource.cci.LocalTransaction as defined in the CCI) supported by the resource adapter. It then calls UserTransaction.begin method to start a JTA transaction before it has completed the local transaction. In this scenario, the EJB component has started but has not completed the local transaction. When the application component attempts to start a JTA transaction by invoking UserTrans-action.begin method, the application server detects it as a transaction demarcation error and throws an exception from the UserTransaction.begin.

[0057] When the application component starts the local transaction, the resource adapter notifies the application server of the LOCAL_TRANSACTION_STARTED connection event. When the component invokes UserTransaction.begin method, the application server detects it as an error condition as it has not received the matching LOCAL_TRANSACTION_COMMITTED or LOCAL_TRANSACTION_ROLLEDBACK event from the resource adapter for the currently active local transaction.

[0058] A transaction system that allows an application server to manage local transactions on a resource manager in a client server environment has been illustrated and discussed in detail. While there have been described above the principles of the present invention in conjunction with various embodiments, the foregoing description is made only by way of example and not as a limitation to the scope of the invention.