On 19.11.2013, at 14:45, Mark Thomas <ma...@apache.org> wrote: > On 19/11/2013 13:32, Carl Boberg wrote: > >> I have here an example of the way we close from the application, (the devs >> have named it dispose). From my untrained non java dev eye we do not seem >> to be doing statement.Close(); and Im curious if that might be the issue? >> If so, why does DBCP handle it nicely and not JDBC? > > Commons DBCP tracks Statements and ResultSets when they are created and > closes the associated Statements and ResultSets when the connection that > created them is returned to the pool. > > Tomcat's JDBC pool does not do this. This is one of the reasons that > Commons DBCP has a larger code base.
JDBC spec states (9.4.4): > An application calls the method Connection.close() to indicate that it has > finished using a connection. All Statement objects created from a given > Connection > object will be closed when the close method for the Connection object is > called. Javadoc of Connection.close() and Statement.close() at least imply that as well. ResultSet’s Javadoc explicitly states that a ResultSet is closed when the statement is closed. AFAICT the JDBC pool uses (as most connection pools) the Connection.close() as means to return a connection to the pool. While I understand that the semantics of completely closing a standalone connection and returning a pooled connection is different, this behavior is still a (presumably deliberate) violation of the spec, and makes the usage non-transparent to the application code. IMO this should be clearly stated in the JDBC pool’s docs, in an easily visible way. Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
