Connection Leak in Java Connection Pools

A connection leak happens when application code borrows a database connection from a pool but fails to return it. Repeated leaks can consume every available connection and eventually prevent other requests from accessing the database.

A connection pool keeps a limited set of database connections ready for reuse. Application code borrows one, performs database work, and should release it so the pool can make it available to another request.

A leak occurs when a borrowed connection is not closed or otherwise returned to the pool. The underlying connection may remain occupied even after the request that borrowed it has finished, reducing the number of connections available for future work.

Leaks are especially dangerous because a small leak per request can accumulate gradually. Once the pool has no available connections, new requests may block while waiting for one or eventually fail with a pool timeout or related database-access error.

In Java, the safest pattern is usually try-with-resources for JDBC resources. Closing a pooled connection normally returns it to the pool rather than physically destroying the database connection, allowing it to be reused.

Key points

• Always return borrowed connections to the pool after use.
• Use try-with-resources to make cleanup happen on both success and failure paths.
• A leak can gradually exhaust the pool even when each individual request appears to work.
• Pool exhaustion can cause requests to wait for a connection or fail after a timeout.

Interview questions

What is a connection leak?

A connection leak occurs when application code obtains a connection from a pool and does not return it. Each leaked connection remains unavailable for reuse. If this happens repeatedly, the pool can eventually run out of available connections. New requests may then wait or fail when the pool timeout is reached.

How does try-with-resources help prevent connection leaks?

Try-with-resources automatically closes resources when execution leaves the block. This includes normal completion and exceptions. For JDBC code, placing the connection in the resource declaration ensures cleanup does not depend on every code path remembering to call `close()`. With a pool, closing the connection generally makes it available for reuse.

What symptoms might indicate a connection leak?

A common symptom is that the pool's active connection count steadily rises while idle connections disappear. Requests may begin waiting for connections and eventually hit connection acquisition timeouts. The problem may appear only under sustained traffic because each request leaks another connection. Pool metrics and application logs can help correlate the growth with particular code paths.

Why can a connection leak be difficult to notice during development?

A pool often has enough capacity that a small leak does not immediately prevent requests from succeeding. Short test runs may therefore finish before enough connections are lost. Production traffic can expose the problem because repeated requests accumulate leaked connections. The issue is also easier to miss when cleanup is present on the normal path but absent in an exception path.

What is the relationship between a connection leak and pool exhaustion?

A leak reduces the pool's effective capacity because connections remain checked out instead of becoming available again. If the leak continues, the number of available connections can approach zero. Once all pool connections are occupied, new acquisition attempts must wait or fail according to the pool's configuration. Therefore, pool exhaustion is often an observable consequence of an ongoing connection leak, although exhaustion can have other causes as well.