Kris Jurka wrote:
> First I don't use our PooledConnection and I'm also a little unclear on
> whose resposibility (CPDS vs the actual pool) certain things are, so this
> is just a combination of anecdotes and looking at the code. Nothing is
> really broken for normal use, but when something goes wrong there is very
> little error detection and fallback. Specifically when a connection to
> the database server is lost via a server restart or even potentially user
> level code Statement.execute("SET client_encoding TO 'LATIN1'); the dead
> connection is not destroyed and will keep being given to clients.
The CPDS/PooledConnection has the responsibility for creating connection
proxy objects and reporting proxy connection closes and connection fatal
errors via a connection listener. The actual pool is responsible for
things like pool size, max idle time, whether to recheck connections
periodically, etc.
Looking at the code, it looks like fireConnectionFatalError() isn't
being called in the normal execution (non-setup) path at all. If it was
being called, then connection pools would have a chance to see the error
via a connection listener and discard the bad connection.
I will look at fixing this. Probably the best way to do it is monitor
the SQLState of thrown exceptions in the InvocationHandler and know
about which states are fatal (e.g. connection failure, driver internal
errors).
-O