Connection acquisition timeout: JDBC connection pool exhaustion
0 reputation · 04 Aug 2024, 22:07 UTC
Goal
Determine whether a connection acquisition timeout should be treated as transient pool exhaustion or as a trigger to fail over to a secondary database. The pool is shared across concurrent request threads, and acquisition waits are bounded by maxWait.
Constraints
Connection pool implementations differ on whether exhaustion triggers automatic failover or leaves retry logic to the application. Behavior varies by pool implementation and version. Adjusting maxWait and maxIdle without observing active, idle, and pending counts can mask unclosed connections.
Should the retry decision live in the pool configuration or in the data access layer? Which pool statistics distinguish exhaustion from a slow query? At what pending-request threshold should the application stop retrying and return an error?