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:38:39 GMT
Hash: SHA1


On 10/26/2009 10:59 PM, Elli Albek wrote:
> To disable caching in DBCP, use configuration option:
> poolPreparedStatements=false

Note that this is the default. Presumably, if you don't know if your
prepared statements are being cached, then they are not being cached.

[Side note: MySQL users should be aware that enabling server-side
prepared statements on your connections will almost certainly result in
disaster. See MysQL's bug database and Connector/J changelog for more

> I don’t remember where exactly you specify it

In your <Resource> definition in context.xml/appName.xml/server.xml

> This is actually something that I would like
> to see built into Tomcat/DBCP (property file configuration). Your system
> admin will thank you.

It is built into Tomcat. Just read the docs for JDBC DataSources:

Though not specifically mentioned, any attribute set on the <Resource>
element in your XML will be set on the DataSource that gets created.
That includes things like logAbandoned, poolPreparedStatements,
defaultTransactionIsolation, etc.

> It may not be possible to use the mysql caching algorithms, since they may
> use features that are not publicly available through JDBC and are part of
> their protocol. I don’t know the source well enough to comment on how it
> works internally.

Also, the Connector/J code itself is released under the GPL which may or
may not be compatible with the APL.

> Specific example of leaks:
> 1.    Close tomcat
> 2.    Connection pool is removed.
> 3.    Request comes in to the war file (the one that is in the closing
> process)
> 4.    Request gets processed.
> 5.    Servlet needs a connection from DBCP.
> 6.    Tomcat does not find the DBCP pool in JNDI, so it recreates it.
> 7.    The newly created connection pool will not be used after this request,
> and will not be closed. If the pool pings the connection, it will stay open.

My understanding was that:

1. Tomcat does not remove the connection pool
2. Once the shutdown process has started, no new requests will be
handled by the currently-shutting-down context

Could these two items give the result you are observing? It's easy
enough to have your webapp close the DataSource (even though it's kinda
stupid that Tomcat doesn't do it for you).

> After all this work, we just shut down tomcat when we update war files.

I would always advocate this approach IMHO: just in case you've damaged
your server at some point, starting fresh with a new deployment is a
good idea.

> 2.    Call shutdown callbacks of different APIs, give developer an option to
> deal with it. For example JMX shutdown process does not happen correctly.

Please log a bug for any legitimate complaints that you may have.
Remember that Tomcat shouldn't shut down anything that the webapp itself

> We got to the
> conclusion that shutting down objects in tomcat was little chaotic and no
> one could say in confidence that using a certain listener API will work
> better than another without spending a few days of tracing the code and
> doing lots of tests.

The servlet specification makes it clear which listeners should be
notified of various events in a very specific order. If Tomcat is not
following these criteria, there's a bug somewhere and you should report
it. If you are using Tomcat-specific listeners, they should be properly
documented and working per the docs. If they are not, please file a bug
and help get things fixed.

- -chris
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla -


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

View raw message