Bug 64083

Summary:	JDBC pool keeps closed connection as available
Product:	Tomcat Modules	Reporter:	Alex Panchenko <alex.panchenko>
Component:	jdbc-pool	Assignee:	Tomcat Developers Mailing List <dev>
Status:	NEW ---
Severity:	normal	CC:	alex.panchenko
Priority:	P2
Version:	unspecified
Target Milestone:	---
Hardware:	All
OS:	All

Description Alex Panchenko 2020-01-17 16:53:01 UTC

In my case the PG driver has closed connecction because of kind of I/O error - an attempt to pass too many parameters for PreparedStatement.

I've created an example: https://github.com/panchenko/tomcat-bugs/blob/master/jdbc-return-closed-connection/src/test/java/org/example/jdbc/ReturnClosedConnectionTest.java

However that closed connection was added to the avaiable ones in the ppol (despite an error during clearWarnings, etc).

And then some other code got that closed connection and failed.

The pool request: https://github.com/apache/tomcat/pull/235

Comment 1 ToolGuy1 2021-08-24 20:00:44 UTC

We have faced this issue in our shop as well with MS SQL Server on version 9.2.x driver for Java 11. Wondering if a configurable option could be added to the code to allow exceptions thrown from clearWarnings() calls to cause the pool to discard connections during return to the pool. Seems like if the underlying DB vendor supports clearWarnings commands that hit the db server ( suspect most do ), that this failing with an Exception should be a decent indicator that the underlying connection is not in good health.

Comment 2 Christopher Schultz 2021-08-27 22:05:06 UTC

(In reply to ToolGuy1 from comment #1)
> We have faced this issue in our shop as well with MS SQL Server on version
> 9.2.x driver for Java 11. Wondering if a configurable option could be added
> to the code to allow exceptions thrown from clearWarnings() calls to cause
> the pool to discard connections during return to the pool. Seems like if the
> underlying DB vendor supports clearWarnings commands that hit the db server
> ( suspect most do ), that this failing with an Exception should be a decent
> indicator that the underlying connection is not in good health.

SQL WARNINGs are not an indication of a broken connection. In fact, they are specifically an indication of a GOOD connection: the database is in fact communicating.

-1 on the suggestion in comment #1, though the original report seems reasonable. to me.