JDBC Connection Pool Exhaustion: Need Clarity on Connection Idle Timeout Settings

Answer first

For long-running batch jobs on Oracle WebLogic JDBC pools, set Inactive Connection Timeout to 300-600 seconds, or slightly less than the expected idle gap between batch runs. Do not use an aggressive timeout below ~30 seconds and avoid keeping idle connections for >1800 seconds during low traffic.

Coupling the timeout with validation on reserve is recommended: enable Test Connections on Reserve with a lightweight query such as SELECT 1 FROM DUAL and keep Test Connections on Return off for batch workloads. This discards stale connections that the database or network may have closed while idle.

Idle timeout does not change WebLogic licensing in 12c or 14c. Memory use scales with the number of idle connections retained, not with the timeout value itself. Each retained physical connection holds a small heap footprint for pool bookkeeping and socket state.

Confirmed facts vs likely explanation

Confirmed behavior

• WebLogic Data Source Connection Pool exposes Inactive Connection Timeout, also shown in the console as Inactive Connection Timeout. When a physical connection is idle longer than this value, the pool closes it.
• Validation strategies are Test Connections on Reserve and Test Connections on Return. Reserve validation checks health at checkout; Return validation checks at checkin.
• JDBCRuntimeMBean exposes ActiveConnectionsCurrent and IdleConnectionsCurrent for runtime observation.

Likely explanation for batch use

• Batch jobs tend to hold connections for long periods with gaps between runs. A moderate idle timeout frees connections during gaps so Max Capacity is available for the next run, reducing exhaustion during peak periods.
• A longer idle timeout keeps connections warm, which can reduce connection creation cost but risks holding capacity idle and masking exhaustion until the next spike.

Assumption: your pool is a standard WebLogic JDBC Data Source without dynamic scaling enabled. If dynamic pooling is enabled, behavior differs.

Steps needed for this case

1. Confirm current setting. In WebLogic Administration Console go to Services > Data Sources > your datasource > Configuration > Connection Pool and note Inactive Connection Timeout.
2. Set Inactive Connection Timeout to 300-600 seconds for batch, or to a value slightly less than the typical idle gap between batch executions. Leave Initial Capacity and Max Capacity unchanged unless sizing is proven insufficient.
3. Enable validation on reserve. Set Test Connections on Reserve to true and use a lightweight validation query. Keep Test Connections on Return false to avoid extra latency on checkin for batch.
4. Verify reclamation at runtime. Inspect JDBCRuntimeMBean attributes ActiveConnectionsCurrent and IdleConnectionsCurrent via WLST or JMX after a batch idle period to confirm idle connections are removed.

Optional safe verification: enable verbose JDBC logging temporarily with -Dweblogic.jdbc.verbose=true to observe checkout/checkin and close events. Disable after verification.

One missing diagnostic detail

The optimal timeout depends on the database server's own idle session timeout and the exact batch interval. If you can share the database's session idle timeout and the expected gap between batch runs, the recommendation can be tightened to avoid DB-side closes while still freeing pool capacity.