tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: DBCP woes (running out of cursors).
Date Tue, 27 Oct 2009 19:24:24 GMT
Hash: SHA1


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:

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
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message