Prevent a connection deadlock. Deadlock
can occur if the application requires more than one concurrent connection
per thread, and the database connection pool is not large enough for
the number of threads. Suppose each of the application threads requires
two concurrent database connections and the number of threads is equal
to the maximum connection pool size. Deadlock can occur when both
of the following are true:
- Each thread has its first database connection, and all are in
use.
- Each thread is waiting for a second database connection, and none
would become available since all threads are blocked.
To prevent the deadlock in this case, increase the maximum
connections value for the database connection pool by at least one.
This will allow at least one of the waiting threads to obtain a second
database connection and avoid a deadlock scenario.
For general
prevention of connection deadlock, code your applications to use only
one connection per thread. If you code the application to require
C concurrent database connections per thread, the connection
pool must support at least the following number of connections, where
T is the maximum number of threads:
T * (C - 1) + 1
The connection pool settings are directly related to the number
of connections that the database server is configured to support.
If you increase the maximum number of connections in the pool and
the corresponding settings in the database are not increased accordingly,
the application might fail. The resulting SQL exception errors would
be displayed in the following location(s):
Enable deferred enlistment. In the application
server environment, deferred enlistment refers to the technique in
which the application server waits until the connection is used before
the connection is enlisted in the application's unit of work (UOW)
scope.Consider the following illustration of deferred enlistment:
- An application component that uses deferred enlistment calls the getConnection method from within a global transaction.
- The application component does not immediately use the connection.
- When the application issues the call for initial use of the connection,
the transaction manager intercepts the call.
- The transaction manager enlists the XA resource for the connection
and calls the XAResource.start method.
- The connection manager associated with the XA resource sends the
call to the database.
Given the same scenario, but the application component does not
use deferred enlistment, the component container immediately enlists
the connection in the transaction. Thus the application server incurs,
for no purpose, an additional load of all of the overhead associated
with that transaction. For XA connections, this overhead includes
the two phase commit (2PC) protocol to the resource manager.
Deferred enlistment offers better performance in the case where a
connection is obtained, but not used, within the UOW scope. The technique
saves the cost of transaction participation until the UOW in which
participation must occur.
Check with your resource adapter provider
if you need to know if the resource adapter provides this functionality.
The application server relational resource adapter automatically supports
deferred enlistment.
Incorporating a deferred enlistment
in your code:
The J2EE Connector Architecture (JCA) Version
1.5 specification calls the deferred enlistment technique
lazy
transaction enlistment optimization. This support is initiated
using the LazyEnlistableManagedConnectionmarker interface, and the
LazyEnlistableConnectionManager() method on the connection manager:
package javax.resource.spi; import javax.resource.ResourceException; import javax.transaction.xa.Xid; interface LazyEnlistableConnectionManager { // application server void lazyEnlist(ManagedConnection) throws ResourceException; } interface LazyEnlistableManagedConnection { // resource adapter }
If the lazy enlistment for the connection is not attempted
by the relational resource adapter, you might receive an ORA-01002
exception. This exception occurs when the ResultSet object associated
with an unshared connection is cached across the transaction boundary.
To solve this problem, add the beginTranForResultSetScrollingAPIs
custom property to the configuration settings for your data source,
and set this property to true. Setting this
custom property to true allows DataSource to add the lazy enlist option
for result operations. The default value is false.
To specify a value for the beginTranForResultSetScrollingAPIs
custom property, in the administrative console, click . Click the name of the data source for which you want
to set this property, and then under Additional Properties, click .
Control connection pool
sharing. You can use the defaultConnectionTypeOverride,
or globalConnectionTypeOverride connection pool custom property for
a particular connection factory or datasource to control connection
sharing , or to globally set a datasource connection type.
The defaultConnectionTypeOverride property changes the default sharing
value for a connection pool. This property enables you to control
connection sharing for direct look-ups. If resource references are
configured for this datasource/connection factory they will take
precedence over this property and the resource ref settings will
be used. For example: if an application is doing direct look-ups,
and you do not want the connections pool shared. set this property
to unshared.
The value specified for the globalConnectionTypeOverride
custom property takes precedence over all of the other connection
sharing settings. For example if you set this property to unshared,
all connection requests are unshared for both direct look-ups, and
resource reference lookups. This property provides you with a quick
way to test the consequences of moving all connections for a particular
datasoure/connection factory to unshared or shared without changing
the resource reference setting in all the deployment descriptors for
an application. The globalConnectionTypeOverride property also enables
you to move between shared, and unshared connections for a particular
datasource or connection factory without having to change any resource
references.
If you specify values for both the defaultConnectionTypeOverride
and the globalConnectionTypeOverride properties, only the values
specified for the globalConnectionTypeOverride property is used to
determine connection sharing type.
![[Updated in October 2011]](../../delta.gif)
To add these
new custom properties to the settings for a data source or connection
factory connection pool, a new connection pool custom property must
be created. To add one of these properties to a data source, use the
administrative console. Click select your data source
from the list . For other J2C or JMS connection factories, navigate
to the connection factory definition in the administrative console.
Then select . Now specify
defaultConnectionTypeOverride or
globalConnectionTypeOverride in the
Name field and
shared or
unshared in the
Value field.
Important: The properties must be set in the Connection
pool custom properties and NOT the general Custom propeties on the data source or connection factory.
![[Updated in October 2011]](../../deltaend.gif)
oct2011
Discard connections. Reap time and unused timeout settings do not cause the idle or
unused connections to be discarded if the servant region is idle.
This situation might cause some DB2 connections to be held longer
than is necessary.
If you prefer to have the connections discarded
at the time specified by a combination of reaper time and unused
timeout settings, even if this preference might cause an idle servant
region to become active again, you can add the nondeferredreaper custom
property to your JDBC driver provider data source settings. When you
add this custom property, connections are discarded at the time specified
by a combination of reaper time and unused timeout settings.
To add this custom property to your JDBC dDriver
provider data source settings, in the administrative console, click Resources > JDBC providers > DB2 Universal JDBC Driver Provider >
Data sources > datasource_name > Custom properties > New. Then specify nondeferredreaper in the Name field, true in the Value field, and java.lang.Boolean in the Type field. This new setting does
not go into affect until you restart the server that is using this
datasource.
Avoid trouble: Activating an
idle servant region for the sole purpose of discarding unused connection,
might cause additional and sometimes undesirable CPU usage. Also,
the following warning message might be logged and should be ignored:
DSRA8200W: DataSource Configuration:
DSRA8020E: Warning: The property 'nondeferredreaper' does not exist on the DataSource
classcom.ibm.db2.jcc.DB2ConnectionPoolDataSource.
gotcha