Sorry I didn't respond earlier -- it's been a busy weekend. Comments
inline...
--David
[EMAIL PROTECTED] 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 :)
Ok....
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: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
