3.14.1 Connection pooling

This functionality pools the resource connections (JDBC connection and resource adapter connections) according to the volume of resource access from the J2EE components, such as servlets, JSPs, and EJBs. By pooling these connections, the resource connection requests from the user application are processed at a high speed.

Organization of this subsection
(1) Preconditions
(2) Generating and initializing the connection pool
(3) Terminating the connection pool
(4) Destroying the connections with exceptions
(5) Notes on using a connection pool
(6) Connection pooling operations

(1) Preconditions

The connection pooling functionality might be available or unavailable depending on the types of resource and the combinations of connection methods. The following table describes the usage of the connection pooling functionality.

Table 3-46 Usability of the connection pooling functionality

Types of resourcesConnection methodUsability
DatabaseDB ConnectorY
Database queueDB Connector for Cosminexus RM and Cosminexus RMY
OpenTP1uCosminexus TP1 ConnectorY
TP1/Message Queue - AccessY
SMTP serverMail configurationN
JavaBeans resources--N
Other resourcesResource adapters conforming to the Connector 1.0 specifications or Connector 1.5 specificationsY
Legend:
Y: Available
N: Not available
--: Not applicable

(2) Generating and initializing the connection pool

The connection pool is generated and initialized during the start processing of the resource. If the connection pool warming up functionality is enabled, a connection is generated at this point. If the connection pool warming up functionality is disabled, a connection is not generated when the resource starts, but is generated when the first connection request occurs.

The connection pool is generated as follows:

(3) Terminating the connection pool

When you undeploy resources or when you terminate the J2EE server, you delete all the connections in the connection pool as well as the connection pool itself. Note that when the connection pool is terminated, all the connection-related transactions are assumed to have concluded.

(4) Destroying the connections with exceptions

If an error such as a database error occurs, the connections stored in the connection pool can no longer be used, and must be quickly discarded from the connection pool.

If an exception occurs in a connection, or in the processing of a product from the connection such as Statement, Application Server destroys the relevant connection from the connection pool when the connection is closed. However, if the conclusion of the local transaction terminates normally, the connection is determined to be normal and is not destroyed.

If an exception occurs in a connection or a product from the connection when a connection is maintained normally, and if you are using a global transaction, Application Server destroys the connection without returning the connection to the connection pool even if the transaction is concluded normally. Therefore, extra connections are generated and might affect the performance.

Note that when a transaction times out, the connections are destroyed from the connection pool regardless of the transaction type.

(5) Notes on using a connection pool

Note the following when you use a connection pool:

(6) Connection pooling operations

The following table describes the connection pooling operations of the resource adapters.

Table 3-47 Connection pool status and operations

Processing of the user application programConnection pool stateConnection pool operations
Connection requestThere are unused connections in the pool.The connection that is unused for the longest time is selected and passed to the user application program. The status of the selected connection in the pool changes to in-use.
There are no unused connections in the pool, and the total number of connections in the pool is less than the value of MaxPoolSize.A new connection is established. The established connection is passed to the user application, and the status of the connection in the pool changes to in-use.
There are no unused connections in the pool, and the total number of connections in the pool has reached the value of MaxPoolSize.An exception is reported to the user application program, and the connection cannot be obtained. To obtain the connection again, specify Retry Count and Retry Interval.
There are unused connections in the pool, but there are no connections with matching authentication information.The following processing is implemented depending on the total number of connections in the pool:
  • If the number of connections in the pool is less than the MaxPoolSize value
    A new connection is established and is passed to the user application.
  • If the number of connections in the pool reaches the MaxPoolSize value
    Among the unused connections, the connections that are pooled first are destroyed, and then new connections are created and passed to the user application.
Releasing the connectionsThere are no errors in the released connections and the connections can be reused.The status of this connection in the pool changes to unused.
The released connection cannot be reused.This connection is destroyed.
--The connection pool warming up functionality is used.When you start a resource adapter or start a server when the resource adapter is already running, connections are generated and pooled up to the value in MinPoolSize.
To use the connection pool warming up functionality, specify Warmup.
Waiting for a connection when connections depleteIf the maximum number of connections are pooled in the connection pool and there are no usable connections in the pool (connection depletion), you can set the connection request to pending.
The pending connection request can obtain a connection as soon as a connection is released.
To wait for a connection when connections deplete, specify RequestQueueEnable and RequestQueueTimeout.
Legend:
--: Not applicable

The following table lists the notes on using the connection pool warming up functionality.

Table 3-48 Notes on using the connection pool warming up functionality

ConditionNotes
Specifying the authentication information (such as user name and password) for container authentication#You must take precautions when you use a combination of multiple user names and passwords with the component-managed sign-on. There is one connection pool for each resource, so when multiple users use one resource, the multiple users share one connection pool. In this case, one user cannot use the connections equal to the value specified as the maximum connection pool value.
In a container-managed sign-on, normally single authentication information is used for a connection request to one connection pool, so no particular precaution needs to be taken.
Specifying MinPoolSizeIn the following cases, the pooled connections might be lesser than the value specified in MinPoolSize:
  • When the connection sweeper executes the connection release processing
  • When you execute the cjclearpool (deleting the connections in the connection pool) command
  • When an error occurs in the connection
When a resource starts, the number of connections specified in MinPoolSize is generated; therefore, starting the server or resource adapter might take more time as compared to when the connection pool warming up functionality is not used.
Also, at this time "value-specified-in-bufSize x memory-for-the-number-of-connections-generated" is allocated in the Java heap area.
If you use the warming up functionality specifying a more than necessary large value in MinPoolSize, the Java heap is used up when you allocate the memory and OutOfMemoryError might occur.
Therefore, set the value of MinPoolSize to no more than the maximum number of concurrent connections of the resource manager used.

#: The connections managed with the connection pool store the authentication information (such as user name and password) for container authentication used during the operation of the warming up functionality.