Build fluency in the vocabulary of a connection checked out of a pool and never returned.
0 / 5 completed
1 / 5
At standup, a dev mentions a code path that opens a database connection but never returns it to the pool on an error branch, so the pool slowly runs out of available connections over time. What is this bug called?
A database connection leak happens when a code path opens a connection but never returns it to the pool, often because an error branch skips the cleanup step, so the pool's available connections shrink over time until none are left. Connection pooling is the healthy mechanism being undermined here, not the bug itself. This kind of leak is especially dangerous because it's invisible under light load and only surfaces once enough leaked connections have accumulated.
2 / 5
During a design review, the team wants every connection checkout to be guaranteed to return to the pool, even if the query in between throws an exception. Which capability supports this?
A try/finally block, or a language's try-with-resources equivalent, guarantees the connection is released back to the pool whether the query in between succeeds or throws, since the finally block always runs. Releasing the connection only in the success path leaves it checked out forever the moment an exception is thrown before that release. This guaranteed-release pattern is the standard defense against a connection leak in exception-heavy code.
3 / 5
In a code review, a dev notices a newly added error branch returns early from a function without going through the same connection-release path every other branch uses. What does this represent?
A code path likely to introduce a connection leak is exactly what an early return skipping the shared release step looks like, since that one branch now checks out a connection it never gives back. A cache eviction policy is an unrelated concept about discarding cached data, not about connection lifecycle. This is precisely the kind of subtle branch a code reviewer needs to catch before it reaches production.
4 / 5
An incident report shows the connection pool became fully exhausted a few hours after a new error-handling branch shipped, because that branch returned early without releasing its checked-out connection back to the pool. What practice would prevent this?
Wrapping every connection checkout in a guaranteed-release pattern, such as try/finally, ensures every branch releases its connection regardless of how it exits, closing off exactly the kind of early return that caused this pool exhaustion. Leaving the new branch with no guaranteed release is precisely what let the leak accumulate until the pool was exhausted. This guaranteed-release discipline is a baseline requirement for any code that checks a connection out of a shared pool.
5 / 5
During a PR review, a teammate asks why the team adds automated connection-pool monitoring and leak detection instead of relying on careful code review alone to catch a missing release. What is the reasoning?
Code review can miss a leak on a rarely exercised error branch, since that branch might not even be triggered during the review or in typical testing. Automated pool monitoring surfaces a shrinking available-connection count in production, giving the team a warning signal before the pool is fully exhausted and the application starts failing outright. The tradeoff is the added operational overhead of instrumenting and alerting on pool metrics continuously.