This problem is caused by Tomcat not cleaning up the JDBC resources defined in context.xml. When a context is stopped the DBCP resource is not notified and the pooled connections are leaked. I've submitted a bug along with a fix (http://issues.apache.org/bugzilla/show_bug.cgi?id=37262) but it was rejected on the grounds that DBCP is an some external library and tomcat should not contain any glueing integration code.
I'm not verry happy about it, because connection leaks seem like a pretty serious issue to me. But hey, why do I complain, I din not pay a dime for Tomcat, right? On 10/26/05, Bogdan Calmac <[EMAIL PROTECTED]> wrote: > When tomcat is stopped the connection is closed. I'll probably submit > the example to bugzilla. Can somebody familiar with the code suggest > which catalina object keeps a reference of the datasource (beside > being registered in JNDI)? > > On 10/26/05, Steve Kirk <[EMAIL PROTECTED]> wrote: > > > > Your code and config below look fine to me, conns seem to be returned OK to > > pool as you say. Sounds to me like the pool itself leaves the database with > > hanging conns in the pool when it goes down. > > > > When you say "If I deploy/undeploy several times" do you stop and restart TC > > between undeploy and redeploy? If so, might be worth trying to see whether > > the problem still happens if you stop and restart TC cleanly rather than > > redeploying the webapp while TC is running? Might help narrow down the > > cause slightly. Might be worth reporting to bugzilla? > > > > > -----Original Message----- > > > From: Bogdan Calmac [mailto:[EMAIL PROTECTED] > > > Sent: Wednesday 26 October 2005 02:18 > > > To: users@tomcat.apache.org > > > Subject: DBCP connection leak after undeploy > > > > > > > > > I've written a simple web application consisting of a servlet which > > > does a select from a table and displays the result. It is then > > > packaged as a war and deployed using the tomcat ant task. After > > > executing the servlet, it is undeployed using the ant task again. > > > stdout confirms that the webapp is deployed and undeployed without > > > errors. The problem is that the connection to the DB is left open even > > > after undeploy. > > > > > > Software used: > > > - tomcat 5.5.9 on Windows > > > - DBCP connection pool > > > - MSSQL server > > > > > > The datasource is defined in META-INF/context.xml with: > > > > > > <Resource name="jdbc/default" auth="Container" > > > type="javax.sql.DataSource" > > > maxActive="5" maxIdle="2" maxWait="10000" > > > username="sa" password="sa" > > > driverClassName="net.sourceforge.jtds.jdbc.Driver" > > > url="jdbc:jtds:sqlserver://localhost/pubs"/> > > > > > > and then referenced in WEB-INF/web.xml with: > > > > > > <resource-ref> > > > <description>DB Connection</description> > > > <res-ref-name>jdbc/default</res-ref-name> > > > <res-type>javax.sql.DataSource</res-type> > > > <res-auth>Container</res-auth> > > > </resource-ref> > > > > > > The code accessing the database is: > > > > > > private long getTitlesCount() { > > > Connection conn = null; > > > Statement stmt = null; > > > ResultSet rs = null; > > > try { > > > InitialContext cxt = new InitialContext(); > > > DataSource ds = (DataSource) cxt.lookup( > > > "java:/comp/env/jdbc/default" ); > > > conn = ds.getConnection(); > > > stmt = conn.createStatement(); > > > rs = stmt.executeQuery("select count(*) from titles"); > > > if (rs.next()) > > > return rs.getLong(1); > > > > > > } > > > catch(Exception e) { > > > System.out.println("Failed to retrive title count > > > from the DB."); > > > e.printStackTrace(); > > > } > > > finally { > > > if (rs != null) try { rs.close(); } catch (Exception e) {} > > > if (stmt != null) try { stmt.close(); } catch (Exception e) {} > > > if (conn != null) try { conn.close(); } catch (Exception e) {} > > > } > > > return -1; > > > } > > > > > > > > > If I deploy/undeploy several times, the number of leaked connections > > > is incremented with 1 each time. > > > > > > If I execute the servlet several times, the number of connections > > > remains constant, which confirms that the servlet releases the > > > connection properly. > > > > > > My guess is that the datasource is not tied to the webapp and it is > > > not notified/released when the webapp is undeployed. > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
