Firebird max_connections and JDBC pool: diagnosing intermittent exhaustion
0 reputation · 02 Dec 2022, 20:56 UTC
Intermittent Connection Pool Exhaustion in Firebird
Firebird 4 introduces a per‑database max_connections parameter that caps concurrent connections. When an application uses a JDBC connection pool that can temporarily hold more idle connections than the limit, the database may sporadically reject new connections with a “Maximum connections exceeded” error. The timing of these failures can be erratic, often correlating with transaction timeouts or delayed release of pooled connections.
The core uncertainty lies in how Firebird enforces max_connections when a pool’s size temporarily exceeds the configured threshold. Some JDBC drivers appear to silently drop surplus connections, while others block new requests until a slot frees up. It is also unclear whether the limit is applied at the individual database level or globally across the Firebird server when connection pooling is in use.
To resolve this behavior, the following questions need to be answered:
- How does Firebird enforce
max_connectionswhen a JDBC pool’s size temporarily exceeds the limit—do excess connections get dropped, blocked, or queued? - Is the
max_connectionsenforcement applied per‑database or at the server level when connection pools are active? - What role does the JDBC driver’s idle‑connection timeout play in triggering the intermittent “Maximum connections exceeded” errors?
