When you use connection pooling, an error connection might be returned for a connection request from a user program if a resource is down or a network error occurs. If you use the connection error detection functionality, you can check whether an error has occurred in the pooled connections and make sure that an error connection is not returned unless otherwise necessary.
You can use the connection error detection functionality together with the connection retry functionality. In this case, if a connection error is detected during a connection request from the user program, you can try to obtain a new connection and return a connection to the user program as soon as the error is restored.
Note that creating and returning a new connection is only enabled when the time for detecting the connection errors is set to "when the connection is requested".
For the times at which the connection errors are detected, see (2) Timing at which error detection is implemented.
The following table describes the usability of the connection error detection functionality.
Table 3-56 Usability of the connection error detection functionality
Resource | Connection method | Usability |
---|---|---|
Database | DB Connector | Y |
Database queue | DB Connector for Cosminexus RM and Cosminexus RM | Y |
OpenTP1 | uCosminexus TP1 Connector | N#1 |
TP1/Message Queue - Access | N#1 | |
SMTP server | mail configuration | N |
JavaBeans resource | -- | N |
Other resources | Resource adapters conforming to the Connector 1.0 specifications or Connector 1.5 specifications | R#2 |
#1: The connection error detection functionality provided by Application Server is not available, but uCosminexus TP1 Connector or TP1/Message Queue - Access provide functionality similar to the connection error detection functionality.
#2: Available when you are using the resource adapters conforming to the Connector 1.5 specifications and when the resource adapter implements the getInvalidConnections method of the ValidatingManagedConnectionFactory interface.
You can choose one of the timings listed in the table as the timing for detecting the connection errors.
Table 3-57 Timing for detecting the connection errors
Error detection timing | Contents |
---|---|
When a connection is requested | Error detection is implemented every time a connection is obtained. In this case, the response performance of the connection request deteriorates, but the probability of obtaining an error connection will lower. This is useful when the frequency of connection requests is less and obtaining an error connection is not permitted. |
Regular intervals | Error detection is implemented at fixed time intervals. By lengthening the error detection interval to some extent, you can reduce the performance deterioration caused by the error detection processing. However, the probability of obtaining an error connection is higher. This is useful when the frequency of connection requests is high and obtaining an error connection is permitted to some extent. |
Note that by default error detection is implemented for a connection request. You can also specify settings to not detect the connection errors.
You specify the settings to switch between the enabling and disabling of connection error detection and the time at which errors are detected as the resource adapter properties. For details on the resource adapter settings, see 3.15.13 Settings in the execution environment.
You can specify a timeout for the response time to detect the connection errors.
If a server error or network error occurs and no response returns from the resource, a response might not be returned even for the execution of the connection error detection. By setting a timeout, the connection check is terminated and the processing can be continued even if no response returns from the resource. Note that you can specify any value for the timeout in error detection in the key specified for the J2EE server in the Easy Setup definition file (the default value is 5 seconds).
The connection management threads are used to operate the timeout for detecting the connection errors. The connection management threads are created in the system according to the maximum number of connections in the connection pool, when the resource adapter starts. The relationship between the number of connection management threads and the maximum number of connections in the connection pool is as follows:
Number-of-connection-management-threads = maximum-number-of-connections-in-the-connection-pool x 2
Therefore, if you set a timeout for detecting the connection errors, a lot of memory is consumed compared to when the timeout is not set. Estimate the required amount of memory appropriately.
Also, if the settings for the maximum number of connections in the connection pool are unlimited, a message is output and the timeout for detecting the connection errors is disabled.
For notes on enabling the timeout for detecting the connection errors, see (5) Notes.
You specify the settings for enabling and disabling the timeout for detecting the connection errors by customizing the resource adapter properties. For details on the resource adapter property settings, see 3.15.13 Settings in the execution environment.
This section describes the operations when the detection of connection errors is implemented for a connection request, and when the detection of connection errors is implemented at regular intervals.
The notes on the error detection functionality are as follows:
When the detection of connection errors is implemented at regular intervals, a sample check is performed for the connections in the connection pool, so even if errors occur on some of the servers, the errors might not be detected.
The notes on enabling the timeout for detecting the connection errors are as follows:
Set the following parameter in the HITACHI Connector Property file so that the connection management threads are not used for resources that cannot use the error detection functionality: