I ended up testing this based on the following Tomcat 5.5.27, JTDS 1.2, Abandoned Logging and Return set to 30 seconds and true.
Test A) Open connection, open Prepared Statement, Open Result set, Close Connection Test B) Open Connection, open prepared Statement, open resultset. Didn't close anything. Test A Resulted in statements and result sets not affecting or throwing errors on the client side. Didn't check to see if cursors were open in the db Test B Resulted in Abandoned Pool thrown after waiting 30 seconds and executing the test again. -----Original Message----- From: Shaun Farrugia [mailto:sfarru...@fry.com] Sent: Wednesday, April 01, 2009 11:00 AM To: Tomcat Users List Subject: RE: Connection Pooling questions Sweet, I set up a test.jsp page that will Connection.close() without rs.close() and ps.close(). Will let you know the results.. And I know you answered this before but I have to ask again. Tomcat is using it's own version of DBCP (based on properties files) Are there any changes to DBCP other than package moves? Can I utilize the DBCP source package and expect that it's the same code tomcat is using? -----Original Message----- From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: Wednesday, April 01, 2009 10:47 AM To: Tomcat Users List Subject: RE: Connection Pooling questions > 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. > 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. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
