tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Smith <>
Subject Re: Connection pooling, is it the right way to do it?
Date Mon, 10 Sep 2007 09:23:41 GMT
Sorry I didn't respond earlier -- it's been a busy weekend.  Comments 

--David wrote:
>> Hi.
>> 1. Your docBase and path attributes are at best optional. As long as 
>> your context.xml is delivered in your webapp's META-INF folder, it 
>> should be used automagically.
> So context.xml and web.xml are fine? And yes, both are dployed with the application

Yes.  Aside from removing docBase and path attributes in context.xml.  
The name of the folder in tomcat's webapps folder will be the default 
for both path and docBase.

>> 2. I would trade the autoReconnect=true parameter to the database url 
>> with a validationQuery attribute in the <Resource .../> element. That 
>> tells the db pool to do use the query to do a quick test of the 
>> connection (and possibly recreate it) before you get it.
> So i should remove autoReconnect=true from url parameter and add the validationQuery
parameter? Which value should i assign to validationQuery?
The validation query can be as simple as 'select 1'.  The point is to 
exercise the connection and make sure it works before attempting to do 
any business.  autoReconnect=true on the db connect url will only 
reconnect after generating an exception.  See the MySQL site for details.

>> 3. I see a lot of places where you catch and summarily eat the exception 
>> with no logging or even passing it up to the method's caller. If you 
>> don't pass it up and it's significant to the response, at least log it. 
>> If you are throwing a new exception in response to an underlying 
>> exception, pass the root cause along.
> I didn't paste the whole code, just the structure of it... there are logs lines in those
catches :)

>> 4. If the Database class is truly stateless (no class instance 
>> variables) like what's listed, static methods are fine. However, I would 
>> personally keep the DataSource object around after the first access in 
>> some manner as a performance optimization for subsequent method calls. 
>> Maybe something to the effect of:
>> db = new Database() ;
>> Object something = db.getSomething() ;
>> Object something2 = db.getSomeOtherThing() ;
> In this way, i would keep the db object around but the DataSource (according to my code)
would be accessed each time due to the getConnection() method that is in each method of Database
class, isn't it?
Right, but the getConnection() code would just something to the effect of:

if ( this.dbsource == null ) {
    // get the datasource
// Continue on with dbsource.getConnection() and finish.

>> In that case, store the DataSource object in the Database class and 
>> don't make any methods static.
>> Otherwise it looks good. Have you tried the code?
> Yes, code is already in use but since i had some problems with the previous installation
of tomcat (after some days connection pooling collapsed) i just wonder if the problem was
the connection pooling or the bad tomcat installation (now i reinstalled it and seems acting
in a better way).
> Anyway, in the way it is, it shouldn't cause any problem in connection pooling, i mean,
the code as it is, could cause any connection problem after some day/weeks of use? Or the
pool is handled in the right way?
> Thanks
I haven't seen any issue if you just make sure to close connections as 
soon as you are done with them.  I see in the code you are doing that, 
so no problem.

To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message