Connection Testing When Database Connections are Created Periodic Connection Testing Testing Reserved Connections
Tuning Data Source Connection Pools 10-5
If a thread appears to be taking longer than normal to connect, the server instance may delay testing on other threads until the abnormally long-running test completes. If that
thread hangs too long in connection testing 10 seconds by default, a pool may declare a DBMS connectivity failure, disable itself, and kill all connections, whether
unreserved or in application hands.
This is very rare, and is intended to relieve the otherwise interminable hangs that can be caused by network cable disconnects and other problems that can lock any JVM
thread which is doing a call in a socket read that the JVM will be unable to break until the OS TCP limit is hit typically 10 minutes. If a pool disables itself in this manner, it
will periodically try to reconnect to the DBMS every 5 seconds by default. Once a new connection can be made, the pool will re-enable itself, and subsequent connection
requests will be served as normal with the pool repopulating itself as load requires.
The query used in testing is determined by the value in Test Table Name. If the value is a table name, the query is select 1 from table_name. If Test Table Name
includes a full query starting with SQL followed by space and the query, WebLogic Server uses that query when testing database connections.
If a connection fails the test, WebLogic Server closes and recreates the connection, and then tests the new connection.
Details about the semantics of connection testing is discussed in the following sections:
■
Connection Testing When Database Connections are Created
■
Periodic Connection Testing
■
Testing Reserved Connections
■
Minimized Connection Test Delay After Database Connectivity Loss
■
Minimized Connection Request Delay After Connection Test Failures
■
Minimizing Connection Request Delay with Seconds to Trust an Idle Pool Connection