Interesting, thanks for mailing to the list. Have you considered whether managing the DBCP resource yourself might help? In other words you don't have to use the TC container-managed method of declaring DBCP resources if you don't want to. If you wrote a ServletContextListener to create and close the pool and make it available to your webapp, you would have more control over these issues (or to put it another way, you could choose to write the "glueing integration code" yourself).
I have this on my "to do" list, because of other issues around using container managed resources. Have not done it yet but I have some quick and dirty code that does it, which I need to combine/adapt. PS I don't think that I have see the problem that you have reported. I run TC 5.5.9 on WinXP with Mysql 4.1.11 and Connector/J 3.1.8, have never noticed that problem, my pools always seem to clean up fine. > -----Original Message----- > From: Bogdan Calmac [mailto:[EMAIL PROTECTED] > Sent: Thursday 27 October 2005 16:49 > To: Tomcat Users List > Subject: Re: DBCP connection leak after undeploy > > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
