Data Sources: Connection Timeout vs. Connection Idle Timeout

dev
1

I wanted to know exactly what “Connection Timeout” was for in a JDBC database configuration and how it compared to “Connection Idle Timeout,” but I couldn’t find the answer documented. So here we go:

Connection Idle Timeout

Per the admin:

Define how long an idle collection will be kept alive, before being closed.

This one’s easy to understand. If a connection hasn’t been used (hasn’t run a query) for N minutes, it will be removed.

Note: In the source code, this gets translated, counterintuitively, to a configuration variable called connectionTimeout.

Connection Timeout

Per the admin:

Define how long a connection will be kept alive, before being closed.

Over on Slack, there were varying assumptions as to what this actually does, so I did some research:

It looks like “Connection Timeout” is responsible for how old a pool connection is allowed to live, period. Say you set it to 1 minute: The connection gets removed one minute after it’s created, regardless of whether it’s in use currently or has ever been in use.

I would think that 99.99% of admins would want to set this to infinity. Maybe there’s an 0.01% niche case where pool connections get corrupted/clogged or something, and you’d want to reap them unceremoniously as a precaution. It seems like that could (problematically) sever executing queries, though.

With that said, I have vague memories that I may have had such a situation (clogged connections) many years ago, which is (I think) why I implemented timeouts in the JDBC URI, itself (rather than implement an indiscriminate reaper via "Connection Timeout):

jdbc:mysql://${DB_PRIMARY_HOST}:3306/${DB_PRIMARY_SCHEMA}?connectTimeout=10000&socketTimeout=120000

References:

  • “Connection Timeout” translates to the liveTimeout variable (don’t ask my why) in the source code: code
  • clear() (the reaper, and an interesting recursive function, BTW): code
  • isLifeCycleTimeout() (based on liveTimeout and used by clear()): code
1 Like