How does a connection pool interact with your thread pool, and what should you monitor?

Every borrow from a connection pool is a blocking wait inside a worker thread. That makes the two pools a two-stage queue: requests queue for a thread, then threads queue for a connection. Sizing one without the other produces either idle threads or a hidden backlog.

What to monitor, because this is where the answer becomes operational: active and idle connections, connection acquisition time (the leading indicator, it rises long before errors), thread pool queue depth, rejected task count, and the 99th percentile of both. HikariCP exposes all of it, and a leakDetectionThreshold catches the connection someone forgot to close in a finally.

Two failure modes to name. A connection held across a remote call multiplies its hold time by the slowest dependency. And a thread that borrows two connections at once, typically a nested transaction, can deadlock the pool entirely when enough threads hold one and wait for another.