tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Elli Albek <e...@sustainlane.com>
Subject Re: DBCP woes (running out of cursors).
Date Wed, 28 Oct 2009 04:21:37 GMT
Thanks for your replies. I agree that Tomcat should be responsible for
all objects that are configured in Tomcat, and the web app should be
responsible for objects that are created by the webapp. Currently it
does not happen properly in tomcat. This is not related to DBCP code,
it is all Tomcat code.

In terms of listeners, I saw that Tomcat executes requests while in
the closing process. This may mean that after the context listener
closed the pool, a new request will cause it to initialize again. We
had a similar problem of things being created after shutdown started,
and there are many permutations of listeners and sequences to test.
Lots of debugging to do here. This again is irrespective of the
listener which I am sure is closing the connection pool, it is a
tomcat lifecycle issue.

> It is built into Tomcat. Just read the docs for JDBC DataSources:
> http://tomcat.apache.org/tomcat-6.0-doc/jndi-datasource-examples-howto.html

I am talking about something else. Basically the XML is short:

<GlobalNamingResources>
	<Resource auth="Container"
	....
	type="javax.sql.DataSource"
	propertiesFile="database_pool_configuration_file.properties" />
</GlobalNamingResources>

No configuration in XML other than JNDI related bindings.

> 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).

That depends on which shutdown it is. Understanding 2 is not correct
from my debugging. You can have a sequence of:
1. Connection pool closed
2. Request sent to servlet

This happens during tomcat shutdown and will trigger a new connection.
I suspect that similar sequence exists during redeploy. I cant recall
exactly what happened in this case, but I remember that it was in more
than one scenario. We decided to shut down tomcat every time and
forget about it, even though we do have a listener that closes pools,
along the same lines as the listener that you wrote I imagine.

If you want to add a listener that closes the pool, I would try adding
tomcat lifecycle listener to the context. You can handle event
Lifecycle.AFTER_STOP_EVENT. Try both listeners (web app and tomcat)
and see which one runs last, and put the code there. You have higher
probability of catching an open connection if you do it later. If the
listener is configured via tomcat and not the web app, you also get a
configuration that each party is responsible for cleaning up its own
bugs, as opposed to web app cleaning up tomcat bugs. Then the vision
of J2EE designers of "separation of roles" materializes :)

Elli

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message