Pooled connection lifecycle and close() semantics

WHAT THIS TESTS Whether you understand that the connection object handed to application code is a managed proxy and that close() means release-to-pool, not disconnect.

A GOOD ANSWER COVERS The pool establishes a set of physical connections to the database, typically lazily or at startup. When the application requests a connection, the pool checks one out, often returning a thin wrapper or proxy around a real underlying connection. The application runs its queries on that handle. When the application calls close(), the wrapper intercepts the call: instead of closing the TCP socket, it cleans up the session, rolling back any open transaction and resetting state, then returns the underlying connection to the pool marked available for the next borrower. The expensive physical connection survives and is reused. The pool only truly tears down a physical connection when it exceeds an idle timeout, reaches a maximum lifetime, is found broken on validation, or the pool shuts down. Crucially, calling close() is still mandatory, because that is what returns the connection; failing to do so leaks it, and under load the pool runs dry and new requests block or time out.

COMMON WRONG ANSWERS Believing close() always severs the network connection, thinking you can skip close() because the pool reclaims automatically, or ignoring that uncommitted transactions must be cleaned on return.

LIKELY FOLLOW-UPS Why try-with-resources or context managers matter; how leaked connections cause pool exhaustion; connection validation and max-lifetime settings.

ONE CONCRETE EXAMPLE A handler borrows a pooled connection, runs a SELECT, and calls close() in a finally block. The pool resets the session and returns the live connection to the idle set. The very next request reuses that same warm physical connection with no new handshake. Had the handler thrown without close(), that connection would be leaked, and after enough leaks the pool empties and requests start timing out.