tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Implementing Connection Pooling
Date Fri, 02 Jul 2010 20:39:03 GMT
Hash: SHA1


On 7/2/2010 8:27 AM, Caldarale, Charles R wrote:
> From: Andrew Laughlin [] Subject:
>> Re: Implementing Connection Pooling
>> Because I won't have this info until run-time.
> Which means you can't configure the appropriate <Resource> elements.
>> It appears Apache Commons has a GenericObjectPool class I can used
>> to implement my own connection pooling facility. However I don't
>> want to go to the trouble if the current method actually works.
> Which it can't possibly do, for the reasons previously given.

Tomcat's <Resource> configuration is intended to be in complete control
of the management of the DataSource, and doing what you are doing might
work for this version of Tomcat, but not for another.

I think, Andrew, that you should probably manage your DataSource
entirely on your own, and configure it 100% in your own

Consider the following (which has already been mentioned by someone
else): once you call getConnection on the BasicDataSource, the
configuration information appears to be set in stone: you can't change
the username and password (or connection URL) at that point.

If you deploy several webapps using the same <Resource> "template", then
will share the same DataSource. Once the first webapp calls
getConnection, the configuration is fixed, and then all webapps share
the same configuration from that point forward, which is likely to be a
security problem.

Tomcat also fails to close-down a DataSource that has been created for a
particular webapp after that webapp is undeployed. I'm not entirely sure
if Tomcat replaces the DataSource when another webapp defines a similar
<Resource> (in META-INF/context.xml, of course). This may be another
situation where security and/or resource management issues arise.

It's not hard to create your own BasicDataSource in a
ServletContextListener and stuff it into the JNDI context yourself. If
you do this, your custom realm should probably work just fine (you might
have to set localDataSource="true" in your <Realm> configuration).

Hope that helps,
- -chris
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla -


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

View raw message