-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chuck,
On 4/1/2009 10:47 AM, Caldarale, Charles R wrote: >> From: Shaun Farrugia [mailto:sfarru...@fry.com] >> Subject: RE: Connection Pooling questions >> >> What happens when the statement isn't closed but the >> connection is returned to the pool? > > The connection object your code sees isn't the real connection; it's > a wrapper created by the pool to control access to the real thing. > Likewise, the ResultSet, Statement, PreparedStatement, etc., objects > visible to the webapp are also wrappers around the real objects. > Using these, the pool knows if the real connection has been cleaned > up properly; the pool won't reuse the connection until it is has > returned to an idle state. That might violate the JDBC spec. Calling Connection.close should close all statements that were created from that connection (JDBC4.0:section 9.4.4). Likewise, closing a statement closes any associated ResultSet objects (section 13.1.4). The spec also allows for statement pooling across connection uses (so the statement survives a connection recycle) but that is required to be hidden from the application and the application should "feel" like the statement is /not/ pooled. My interpretation of this is that Connection.close in a pooled environment should close the result sets and statements, at least in such a way that the application can't tell the difference. If the statements are intended to be pooled, then they can survive, but the result sets should go bye-bye. >> I have some code blocks that don't have a finally block >> to close the result set and prepared statement. If an >> exception happens the statement and the result set stay >> open but the connection gets returned to the pool. > > A brief scan of the code in commons-dbcp indicates that when a > Connection.close() is done, an attempt is made to close the associated > Statement and ResultSet objects. Some experimentation (which I don't > have time for right now) would make me more comfortable with that > observation. I think the JDBC spec should strengthen your faith at least in the correctness of this behavior... whether it is completely implemented or the implementation meets your (or my) interpretation is another matter. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAknT1dIACgkQ9CaO5/Lv0PCd1gCcD747GJijxm/aM8foUY6wSXeo cGUAniZUoLg7j7+rnIf0RtGPZK0VcDuJ =c+bE -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
