Browse Prior Art Database

Method to enable integration of resource adapters that provide different types of connection for different transaction contexts with the Java Connector Architecture

IP.com Disclosure Number: IPCOM000016142D
Original Publication Date: 2002-Jul-14
Included in the Prior Art Database: 2003-Jun-21
Document File: 3 page(s) / 58K

Publishing Venue

IBM

Abstract

Disclosed is a method for integrating a resource adapter that requires the use of different types of connection in different types of transaction context with the Java* Connector Architecture (JCA). The JCA states that an Enterprise Information System (EIS) whose resource adapter indicates its level of transaction support as XATransaction must support both Java Transaction API (JTA) transactions and resource manager local transactions. The JCA then assumes that a single connection object provided by such a resource adapter may be used in both types of transaction. There are, however, resource adapters that require a different type of connection for each type of transaction. This method enables these resource adapters to be used with the JCA. The method utilises a mechanism provided by the JCA for sharing connections among applications in order to improve efficiency and performance. When an application requests a connection it is given a handle to a managed connection which, in turn, references the physical connection. If a resource is marked as Shareable then there may be more than one handle to the same managed connection. Consequently, when the application leaves a particular transaction context, the JCA connection manager must disassociate the handle from the original managed connection as other applications may still be using the managed connection in that transaction context. The connection manager then finds a set of potential managed connections from its pool, based on the request information and security information it knows about, and passes them to the matchManagedConnections method of the resource adapter's managed connection factory. This is to allow the resource adapter to pick the most suitable managed connection. The connection manager then associates the handle with this new managed connection. In this method, each managed connection is marked with the type of transaction that its physical connection supports. Then, when the matchManagedConnections method is invoked at a transaction boundary, the resource adapter determines the type of the new transaction context and returns a managed connection from the provided set that supports that type of transaction. If it is does not find a suitable managed connection, it returns null and, as dictated by the JCA, the createManagedConnection method will be invoked by the connection manager. The resource adapter then creates a connection of the appropriate type. For example, a particular resource adapter has type A and type B connections. Type A connections must be used in resource manager local transactions and type B connections in JTA transactions. A J2EE application, operating outside of a JTA transaction, obtains a connection handle using the standard JCA APIs, passing in the username 'dave'. As shown in the figure below, the connection manager has a pool currently only containing managed connections of type B with various usernames. The connection manager obtains a set of managed connections with the correct username and passes them to matchManagedConnections. The resource adapter discovers it is outside of a JTA transaction and, as described above, returns null to indicate that none of the managed connections match. The connection manager then calls

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 3

  Method to enable integration of resource adapters that provide different types of connection for different transaction contexts with the Java Connector Architecture

Disclosed is a method for integrating a resource adapter that requires the use of different types of connection in different types of transaction context with the Java* Connector Architecture (JCA). The JCA states that an Enterprise Information System (EIS) whose resource adapter indicates its level of transaction support as XATransaction must support both Java Transaction API (JTA) transactions and resource manager local transactions. The JCA then assumes that a single connection object provided by such a resource adapter may be used in both types of transaction. There are, however, resource adapters that require a different type of connection for each type of transaction. This method enables these resource adapters to be used with the JCA.

     The method utilises a mechanism provided by the JCA for sharing connections among applications in order to improve efficiency and performance. When an application requests a connection it is given a handle to a managed connection which, in turn, references the physical connection. If a resource is marked as Shareable then there may be more than one handle to the same managed connection. Consequently, when the application leaves a particular transaction context, the JCA connection manager must disassociate the handle from the original managed connection as other applications may still be using the managed connection in that transaction context. The connection manager then finds a set of potential managed connections from its pool, based on the request information and security information it knows about, and passes them to the matchManagedConnections method of the resource adapter's managed connection factory. This is to allow the resource adapter to pick the most suitable managed connection. The connection manager then associates the handle with this new managed connection.

     In this method, each managed connection is marked with the type of transaction that its physical connection supports. Then, when the matchManagedConnections method is invoked at a transaction boundary, the resource adapter determines the type of the new transaction context and returns a managed connection from the provided set that supports that type of transaction. If it is does not find a suitable managed connection, it returns null and, as dictated by the JCA, the createManagedConnection method will be invoked by the connection m...