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.
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 resources | Connection method | Usability |
---|---|---|
Database | DB Connector | Y |
Database queue | DB Connector for Cosminexus RM and Cosminexus RM | Y |
OpenTP1 | uCosminexus TP1 Connector | Y |
TP1/Message Queue - Access | Y | |
SMTP server | Mail configuration | N |
JavaBeans resources | -- | N |
Other resources | Resource adapters conforming to the Connector 1.0 specifications or Connector 1.5 specifications | Y |
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:
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.
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.
Note the following when you use a connection pool:
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 program | Connection pool state | Connection pool operations |
---|---|---|
Connection request | There 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:
| |
Releasing the connections | There 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 deplete | If 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. |
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
Condition | Notes |
---|---|
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 MinPoolSize | In the following cases, the pooled connections might be lesser than the value specified in MinPoolSize:
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.