tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nikola Milutinovic <>
Subject Re: Right way to close database connection pool
Date Thu, 06 Aug 2009 09:58:02 GMT
Why exactly would you want connection pool to be closed by TC?

I understand your point of view - you have that one web application and it is using the pool
and you are seeing something that looks like a leak.

Take a look from Tomcat's perspective. It has a JNDI bound resource, DataSource in this case.
TC has no way of knowing that that particular resource is being exclusively used by just that
one application. It can be used by several applications. So, why close it?

On the other hand, even if it knew that the DS is being exclusively used by your web application,
which has been undeployed at some point, why should it close (and then re-open) the DS?

DataSource pool is managing a pool of connections, it is opening, closing and recycling connections
as needed. When the container (TC) goes down, I would expect it to close the entire pool,
but I don't see the need for closing it while TC is up and running.


From: Christopher Schultz <>
To: Tomcat Users List <>
Sent: Wednesday, August 5, 2009 7:35:40 PM
Subject: Re: Right way to close database connection pool

Hash: SHA1


On 8/5/2009 1:05 PM, Filip Hanik - Dev Lists wrote:
> you would need to listen for context destroyed, and cast the datasource
> to call close() on it

When Tomcat re-deploys an application, is the existing DataSource
trashed and re-created? When that happens, are the old connections
closed? The OP's comments suggest that the old connections are not being
closed. Is this expected behavior?

Why are Tomcat-created, webapp-specific (that is, <Resource>s from
META-INF/context.xml) DataSources not cleaned-up after web application
un-deployment? It would seem that those resources are not applicable to
any other webapp (because they came from a specific webapp's
configuration) and should be torn-down during an undeployment.

Am I missing a use case where this makes sense?

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


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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message