Unshareable and shareable connections
The product supports both unshareable and shareable connections. An unshareable connection is not shared with other components in the application. The component using this connection has full control of this connection.
You can share a shareable connection with other components within the same transaction as long as each getConnection request has the same connection properties. To enable connection sharing for data sources, the following connection properties must be the same:
- Java Naming and Directory Interface (JNDI) name. While not actually a connection property,
this requirement simply means that you can only share connections from the
same dataSource in the same server.
- Resource authentication
- In relational databases:
- Isolation level (corresponds to Access Intent in the CMP bean)
- Readonly
- Catalog
- TypeMap
- Isolation level (corresponds to Access Intent in the CMP bean)
To enable connection sharing for resource adapters within the same transaction, the following connection properties must be the same:
- JNDI name. While not actually a connection property, this requirement
simply means that you can only share connections from the same resource adapter
in the same server.
- Resource authentication
Access to a resource marked as Unshareable means that there is a one-to-one relationship between the connection handle a component is using and the physical connection the handle is associated with. This access implies that every call to getConnection returns a connection handle solely for the requesting user. Typically, choose unshareable if you might do things to the connection that could result in unexpected behavior occurring to another application that is sharing the connection (for example, changing the isolation level).
Marking a resource as Shareable allows for greater scalability. Instead of creating new physical connections on every getConnection invocation, the physical connection (that is, managed connection) is shared through multiple connection handles, as long as each getConnection request has the same connection properties. But, sharing a connection means that each user must not do anything to the connection that could change its behavior and disrupt a sharing partner (for example, changing the isolation level). The user also cannot code an application expecting sharing to take place because it is up to the run time to decide whether or not to share a particular connection.
For WebSphere Application Server, all sharing of connections is relative to the current Unit of Work (UOW) boundary. Anyone within a specific transaction, when getting a connection from a specific connection pool, gets a handle to the same physical connection (if the sharing properties are the same).
Factors that determine sharing
The listing here is not an exhaustive one. The product might or might not share connections under different circumstances.
- Only connections acquired with the same resource reference (resource-ref),
which specifies the res-sharing-scope as Shareable, are candidates
for sharing. The resource-ref properties of res-sharing-scope and res-auth
and the IBM extension isolationLevel help determine if it is possible to share
a connection. IBM extension isolationLevel is stored in IBM deployment descriptor
extension file; for example: ibm-ejb-jar-ext.xmi.
- You can only share connections that are requested with the same properties.
- Connection Sharing only occurs between different component instances if
they are within a transaction (container- or user-initiated transaction).
- Connection Sharing only occurs within a sharing boundary. Current sharing
boundaries include Transactions and LocalTransactionContainment (LTC)
boundaries.
- Connection Sharing rules within an LTC Scope:
- For shareable connections, only Connection Reuse is allowed within
a single component instance. Connection reuse occurs when the following actions
are taken with a connection: get, use, commit/rollback, close; get, use,
commit/rollback, close. Note that if you use the LTC resolution-control of ContainerAtBoundary then
no start/commit is needed because that action is handled by the container.
The connection returned on the second get is the same connection as that returned on the first get (if the same properties are used). Because the connection use is serial, only one connection handle to the underlying physical connection is used at a time, so true connection sharing does not take place. The term "reuse" is more accurate.
More importantly, the LocalTransactionContainment boundary enclosing both get actions has not completed; no cleanUp() method invocation has occurred on the ManagedConnection object. Therefore the second get action inherits all of the connection properties set during the first getConnection() call.
- For shareable connections, only Connection Reuse is allowed within
a single component instance. Connection reuse occurs when the following actions
are taken with a connection: get, use, commit/rollback, close; get, use,
commit/rollback, close. Note that if you use the LTC resolution-control of ContainerAtBoundary then
no start/commit is needed because that action is handled by the container.
- Shareable connections between transactions (either container-managed transactions
(CMT), bean-managed transactions (BMT), or LTC transactions) follow these
caching rules:
- In general, setting properties on shareable connections is not allowed
because a user of one connection handle might not anticipate a change made
by another connection handle. This limitation is part of the J2EE 1.3 standard.
- General users of resource adapters can set the connection properties on
the connection factory getConnection call by passing them in a ConnectionSpec.
However, the properties set on the connection during one transaction are not guaranteed to be the same when used in the next transaction. Because it is not valid to share connections outside of a sharing scope, connection handles are moved off of the physical connection with which they are currently associated when a transaction ends. That physical connection is returned to the free connection pool. Connections are cleaned before going in the free pool. The next time the handle is used, it is automatically associated with an appropriate connection. The appropriateness is based on the security login information, connection properties, and (for the JDBC API) the isolation level specified in the extended resource reference, passed in on the original request that returned the current handle. Any properties set on the connection after it was retrieved are lost.
- For JDBC users, WebSphere Application Server provides an extension to
enable you to pass the connection properties through the ConnectionSpec.
Use caution when setting properties and sharing connections in a local transaction scope. Ensure that other components with which the connection is shared are expecting the behavior resulting from your settings.
- In general, setting properties on shareable connections is not allowed
because a user of one connection handle might not anticipate a change made
by another connection handle. This limitation is part of the J2EE 1.3 standard.
- You cannot set the IsolationLevel when using a shareable connection for the JDBC API using a relational resource adapter in a global transaction. The product provides an extension to the resource reference to enable you to specify the isolation level. If your application requires the use of multiple isolation levels, create multiple resource references and map them to the same data source or connection factory.
Sharing a connection with a CMP bean
WebSphere Application Server allows you to share a physical connection between a CMP bean, a BMP bean, and a JDBC application to reduce the resource allocation or deadlock scenarios. There are several ways to ensure that all these Entity beans and the JDBC applications are sharing the same physical connection.
- Sharing a connection between CMP beans or methods
When all CMP bean methods use the same access intent, they all share the same physical connection. A different access intent policy triggers the allocation of a different physical connection. For example, a CMP bean has two methods; method 1 is associated with wsPessimisticUpdate intent, whereas method 2 has wsOptimisticUpdate access intent. Method 1 and method 2 cannot share the same physical connection within a transaction. In other words, an XA DataSource is required to run in a global transaction.
You can experience some deadlocks from a database if both methods try to access the same table. Therefore, sharing a connection is determined by the access intents that are defined in the CMP methods.
- Sharing a connection between CMP and BMP beans
There are two options to ensure that both CMP and BMP beans share the same physical connection:
- Define the same access intent on both CMP and BMP bean methods. Because
both use the same access intent, they share the same physical connection.
The advantage to using this option is that the backend is transparent to a
BMP bean; however, this BMP is not portable because it uses the WebSphere
extended API to handle the isolation level. For
more information, refer to the code example in Example:
Accessing data using IBM extended APIs to share connections between container-managed
and bean-managed persistence beans.
- Determine the isolation level that the access intent uses on a CMP bean method, then use the corresponding isolation level that is specified on the resource reference to look up a data source and a connection. This option is more of a manual process, and the isolation level might be different from database to database. For more information refer to the isolation level and access intent mapping table: Access intent isolation levels and update locks and the Isolation level and resource reference section.
- Define the same access intent on both CMP and BMP bean methods. Because
both use the same access intent, they share the same physical connection.
The advantage to using this option is that the backend is transparent to a
BMP bean; however, this BMP is not portable because it uses the WebSphere
extended API to handle the isolation level. For
more information, refer to the code example in Example:
Accessing data using IBM extended APIs to share connections between container-managed
and bean-managed persistence beans.
- Sharing a connection between CMP and a JDBC application that is used
by a servlet or a Session Bean
Determine the isolation level that the access intent uses on a CMP bean method, then use the corresponding isolation level specified on the resource reference to look up a data source and a connection. For more information refer to Access intent isolation levels and update locks and Isolation level and resource reference.
Resource adapter
Connection factory
Data sources
Connection pooling
Connection handles
Isolation level and resource reference
Using the transaction service
Data access application programming interface support
Connection considerations when migrating servlets, JavaServer Pages, or enterprise session beans
Access intent and isolation level
Access intent policies