+

Search Tips   |   Advanced Search

Connection handles

A connection handle is a representation of a physical connection. To use a backend resource, such as a relational database in WebSphere Application Server, you must get a connection to that resource. When you call the getConnection() method, you get a connection handle returned. The handle is not the physical connection. The physical connection is managed by the connection manager.

There are two significant configurations that affect how connection handles are used and how they behave. The first is the res-sharing-scope, which is defined by the resource-reference used to look up the DataSource or Connection Factory. This property tells the connection manager whether or not we can share this connection.

The second factor that affects connection handle behavior is the usage pattern. There are essentially two usage patterns. The first is called the get/use/close pattern. It is used within a single method and without calling another method that might get a connection from the same data source or connection factory. An application using this pattern does the following:

  1. gets a connection

  2. does its work

  3. commits (if appropriate)

  4. closes the connection.

The second usage pattern is called the cached handle pattern. This is where an application:

  1. gets a connection

  2. begins a global transaction

  3. does work on the connection

  4. commits a global transaction

  5. does work on the connection again

A cached handle is a connection handle that is held across transaction and method boundaries by an application. Keep in mind the following considerations for using cached handles:

The following code segment shows the cached connection pattern.

Connection conn = ds.getConnection();
ut.begin();
conn.prepareStatement("....."); --> Connection runs in global transaction mode
...
ut.commit();
conn.prepareStatement(".....");   ---> Connection still valid but runs in autoCommit(True);
...


Unshareable connections

Some characteristics of connection handles retrieved with a res-sharing-scope of unshareable are described in the following sections.


Shareable connections

Some characteristics of connection handles that are retrieved with a res-sharing-scope of shareable are described in the following sections.


Lazy connection association optimization

The Java EE Connector (J2C) connection manager implemented smart handle support. This technology enables allocation of a connection handle to an application while the managed connection associated with that connection handle is used by other applications (assuming that the connection is not being used by the original application). This concept is part of the Java EE Connector Architecture (JCA) 1.5 specification. (We can find it in the JCA 1.5 specification document in the section entitled "Lazy Connection Association Optimization.") Smart handle support introduces use a method on the ConnectionManager object, the LazyAssociatableConnectionManager() method , and a new marker interface, the DissociatableManagedConnection class. We must configure the provider of the resource adapter to make this functionality available in the environment. (In the case of the RRA, WebSphere Application Server itself is the provider.) The following code snippet shows how to include smart handle support:
package javax.resource.spi;
import javax.resource.ResourceException;

interface LazyAssociatableConnectionManager { // application server     void associateConnection(
        Object connection, ManagedConnectionFactory mcf, ConnectionRequestInfo info) throws ResourceException;
}

interface DissociatableManagedConnection { // resource adapter
    void dissociateConnections() throws ResourceException;
}

This DissociatableManagedConnection interface introduces another state to the Connection object: inactive. A Connection can now be active, closed, and inactive. The connection object enters the inactive state when a corresponding ManagedConnection object is cleaned up. The connection stays inactive until an application component attempts to re-use it. Then the resource adapter calls back to the connection manager to re-associate the connection with an active ManagedConnection object.


Related concepts

  • Relational resource adapters and JCA
  • Data sources
  • Connection pooling
  • Unshareable and shareable connections
  • Requirements for setting data access isolation levels