I am completely new to dbcp, so perhaps I am barking up the wrong tree here, but this feature is exactly what I was just now looking for in the documentation.
BTW, I wanted this for a postgres setup, not mysql so the feature is generic.
There are good reasons to have a maximum connection life.
+ It is handy for graceful downtime free maintenance by allowing tomcat tcp sessions to be migrated one at a time
+ It help deals with things that shouldn't happen like memory leaks in a database backend. This is not a problem
I am currently experiencing, but it a good practice to have a maximium lifetime in case a leak was introduced this
would make it non-critical to operations.
A connect costs a few milliseconds. Having a lifetime of 10 seconds would be a huge benefit for failover. A connect costs a milliseconds, re-prepares are often cheap and may actually improve performance for me on this app.
Basically the high level design was looking like this:
[ App ] -> [ DBCP ] -> [ pgbouncer ] -> [ postgres cluster ]
(I could eliminate pgbouncer here and replace it with stateful NAT but by having pgbouncer there I can have pgbouncer allow connect / logins to succeed and cause things to merely block briefy during switchover so the change is more transparent.)
So, I think this is useful.
If dbcp had it ... I would probably use dbcp. I may or may not use it as it stands now..