Correct. On 10/31/05, Steve Kirk <[EMAIL PROTECTED]> wrote: > > 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] > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
