-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Elli,
On 10/26/2009 9:01 PM, Elli Albek wrote: > 2. If your JDBC driver supports caching of prepared statements and > metadata, do it in the driver and disable this in DBCP. IMO DBCP > does a poor job at best in caching. We use mysql and its JDBC driver > is doing an excellent job. I don't believe that DBCP caches any metadata, and there are no settings to tweak that AFAICT. > 3. Your JDBC driver may already be caching metadata that DBCP is > caching. In this case you are caching the same data twice. Make sure > it dose not happen, it is a big memory overload on the JVM. Do you mean PreparedStatements? > 4. Tomcat has a problem doing a clean shutdown of DBCP, and other > JNDI resources. I traced in the debugger dangling connection pools > that are created during the shutdown process. If your pool is > configure to ping the connections once in a while, they can stay open > for a long time, possibly forever. Our solution is custom extension > that cleans up pools, which works in conjunction with our extended > implementation of DBCP. This was recently discussed on this list: http://tomcat.markmail.org/search/?q=%22right+way+to+close+database+connection+pool%22+list%3Aorg.apache.tomcat.users#query:%22right%20way%20to%20close%20database%20connection%20pool%22%20list%3Aorg.apache.tomcat.users%20order%3Adate-forward+page:1+mid:xq2q5wk6skv3exoz+state:results If that link doesn't work, search MarkMail for "Right way to close database connection pool" which is the subject of the thread. I contributed the code for a ServletContextListener that you can use to shut down your DataSource just before the servlet context is discarded. This ought to resolve any issues you may be having, and you're of course welcome to look at my code and/or make comments. Note that this resource issue has nothing to do with commons-DBCP: it is entirely Tomcat's "fault" that the DataSource is allowed to live forever. > I am not aware of any way to completely avoid dangling connection > pool after hot deployment under load. We tried to fix this but it got > too complicated, it is much easier to restart Tomcat and swallow the > bitter pill. I believe tools like LambdaProbe will also allow you to shut down DataSource objects as well. If you can afford to stop your webapp, close the DataSource, then re-reploy, then this may be an option for you. Of course, if you have time to do this, you probably have time to stop Tomcat, update your WAR file, and start Tomcat again. > You can still do hot deployment of war files that do not access the > database, though it is possible that the same leaks will leave lots > of hanging objects of other types (like email clients, JMS clients, > thread pools, HttpClient, etc). These things ought to clean themselves up by using ServletContextListeners as well. Certainly, it's surprising (to me, at least) that Tomcat creates and configures a resource yet never cleans it up, but anything your webapp does also needs to be un-done by your webapp. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrnSOgACgkQ9CaO5/Lv0PC7ywCcCdxixuwTCCm1FdxlFxmu5X9u GkMAnjCcuSwqBCwSyDKd2RgwIvP+9iM4 =8NRT -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
