I was thinking that you could write your own ServletContextListener code to create/close the pool, so that you do not have to rely on TC to manage DBCP via JNDI. I am planning to do this myself sometime soon, for other reasons (you've just given me another one). I'm thinking that by not using JNDI, I would not encounter of the problem you mention below, because the problem is related to the TC-JNDI interface. Does that sound right to you?
> -----Original Message----- > From: Bogdan Calmac [mailto:[EMAIL PROTECTED] > Sent: Monday 31 October 2005 16:50 > To: Tomcat Users List > Subject: Re: DBCP connection leak after undeploy > > > In our company we share several Tomcat servers for all developers, so > that's why we use deploy/undeploy instead of start/stop. > > As a workaround for this problem, you can create a > ServletContextListener and close the datasource yourself in > contextDestroyed(). I used refection here to avoid compile time > dependency on Tomcat DBCP. > > try > { > Context initCtx = new InitialContext(); > ds = (DataSource) > initCtx.lookup("java:comp/env/jdbc/YourDSName"); > if ("org.apache.tomcat.dbcp.dbcp.BasicDataSource".equals( > ds.getClass().getName())) > { > Method closeMethod = ds.getClass().getMethod("close"); > closeMethod.invoke(ds); > } > catch (Exception e) > { > yourLog.error("Failed to close DBCP DataSource.", e); > } > > The above code would actually not work because JNDI is destroyed by > the time contextDestroyed() is called (see > http://issues.apache.org/bugzilla/show_bug.cgi?id=37264) so you could > do the lookup and cache the datasource object in contextInitialized(). > > On 10/28/05, Steve Kirk <[EMAIL PROTECTED]> wrote: > > Yes, confirmed, I get the same problem. (I used the > undeploy command from > > within the NetBeans runtime window, and also checked using > the undeploy link > > in the browser from /manager/html/). Conns are cleaned up OK if you > > start/stop TC, but not if you undeploy the app with TC > still running, as you > > said. > > > > Having said that, does anyone undeploy apps like this on > production servers? > > I wouldn't think so, but then again I suppose it might > affect ISP type > > users. > > > > PS I have these config values: > > maxActive="10" > > maxIdle="5" > > > > > -----Original Message----- > > > From: Bogdan Calmac [mailto:[EMAIL PROTECTED] > > > Sent: Thursday 27 October 2005 19:27 > > > To: Tomcat Users List > > > Subject: Re: DBCP connection leak after undeploy > > > > > > > > > > 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. > > > > > > You might not have the same setup. I would suggest to try the > > > following: > > > > > > 1. make sure you define the datasource in > META-INF/context.xml and you > > > access the DB using that JNDI datasource. > > > 2. package your webapp as a war > > > 3. Do a "netstat" and note how many DB connections are open > > > 4. deploy your webapp using the ant task or the manager webapp > > > 5. Access your webapp to use the DB > > > 6. Do another "netstat" to confirm that there is one more DB > > > connection (which is now pooled) > > > 7. undeploy your webapp using the ant task or the manager > webapp (do > > > not stop tomcat) > > > 8. Do one more "netstat" and I would be very surprised if > the extra > > > connection was closed :-) > > > > > > Another explanation for your finding could be setting > maxIdle="0" in > > > the resource definition, but that practically disables pooling. > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
