Firebird max_connections and JDBC pool: diagnosing intermittent exhaustion

Short answer

Firebird 4's MAX_CONNECTIONS is enforced per database, is checked at attachment time, and is rejected immediately — excess connection attempts are never queued or blocked server-side. The intermittency comes from the pool, not Firebird: when your JDBC pool's maximum size exceeds the database limit, whether a given request fails depends on how many physical attachments happen to be open at that instant. Idle-timeout timing and slow connection release shift that count around, which is why the errors look random.

How enforcement actually works

Each attachment to a database counts toward that database's own MAX_CONNECTIONS value. Connections to other databases on the same server are governed by their own settings — the limit is not global. When the count is reached, a new attach attempt fails immediately with a "maximum connections exceeded" error (the Firebird isc_max_connections_exceeded condition, surfaced through Jaybird as a connection failure).

Jaybird does not silently drop surplus connections, and Firebird does not queue them. The failure is raised to the pool (HikariCP, DBCP, etc.), which typically treats it as a connection-creation failure — retrying, propagating an exception, or waiting for an existing pooled connection to be returned. Which behavior you see depends on your pool's configuration, which explains why different drivers/pools appear to behave differently.

Why it correlates with idle timeouts and slow release

The pool's idle-connection timeout is the mechanism that brings the physical attachment count back down after a load spike. If the spike pushed the pool to open more physical connections than MAX_CONNECTIONS allows, the surplus stays attached until the idle timeout closes it. During that window, any burst of new requests that exhausts the pool's valid connections forces the pool to open a new physical connection — which Firebird rejects. Transaction timeouts or long-running transactions delay connection return to the pool, stretching that window further. Hence: sporadic, load-correlated failures.

Fix and verification

1. Size the pool below the limit. Set the pool's maximumPoolSize (per database, summed across all application instances connecting to that database) to be at or below MAX_CONNECTIONS, leaving headroom for administrative attachments (isql, monitoring tools, backup).
2. Confirm the current attachment count. Run SELECT COUNT(*) FROM MON$ATTACHMENTS; against the database during a failure window and compare it to the configured limit.
3. Run a controlled test. Temporarily set the pool size well below the limit. If the errors stop, pool oversubscription was the cause.
4. Align timeouts. Set the pool's idle timeout and max lifetime shorter than any server-side idle connection cleanup, and ensure connections are returned promptly (check for connection leaks — most pools offer a leak-detection threshold).

Note that changing MAX_CONNECTIONS (via ALTER DATABASE or database configuration) applies to new attachments; existing connections still count until closed. Raising the limit without shrinking the pool only postpones the problem if the application leaks or holds connections.

One caveat

This analysis assumes Firebird 4.x with Jaybird 5/6 and a mainstream pool. If your failures persist even with the pool sized below the limit, capture the exact error text and the MON$ATTACHMENTS count at failure time — that combination distinguishes a true limit hit from an unrelated network or authentication failure masquerading as exhaustion.