On Fri, 8 Nov 2002, Keates, Mark wrote:
> Date: Fri, 8 Nov 2002 05:20:44 -0500
> From: "Keates, Mark" <[EMAIL PROTECTED]>
> Reply-To: Jakarta Commons Users List <[EMAIL PROTECTED]>
> To: 'Jakarta Commons Users List' <[EMAIL PROTECTED]>
> Subject: RE: [dbcp] Idle connections
>
> Hi Craig, thanks for the reply,
>
> > If you are using the documented data source factory for Tomcat 4.1
> > (org.apache.commons.dbcp.BasicDataSourceFactory), you should be able to
> > set the "validationQuery" property to an SQL query (i.e. a SELECT
> > statement) that will be executed by the pool before a connection is
> > returned. If the query fails, that connection instance will be thrown
> > away. This should cover both of the scenarios you describe.
>
> I'm currently using TC 4.0.4 so can the dbcp package be used with that
The DBCP package should be usable with Tomcat 4.0.x, but is not the
default. You need to include commons-dbcp.jar and commons-pool.jar (and
any other commons packages they rely on) in your $CATALINA_HOME/common/lib
directory, and include the following in your <ResourceParams> element for
the data source:
<parameter>
<name>factory</name>
<value>org.apache.commons.dbcp.BasicDataSourceFactory</value>
</parameter
> or should I upgrade to 4.1.12?
This one uses commons-dbcp by default.
> I've also just noticed that I'll should also
> go from Java 2 1.3 to 1.4 for the javax.sql.DataSource.
The commons-dbcp package will run on either 1.3 or 1.4 (as long as you
avoid the new methods that were added in 1.4), but you'll like the
performance improvements of 1.4 generally. Go for 1.4.1 (the latest
released version).
>
> How would the validationQuery property statisfy the idle connection
> scenario,
> doesn't this statement only get executed when a connection request is made,
> or
> is the validateObject method in PoolableConnectionFactory called
> periodically?
>
The validation query is called every time you call
datasource.getConnection() -- it is used to ensure that the connection
just retrieved from the pool is not stale (due to timeouts or recycling
the database). If it is, the pool throws that one away and gets you a new
one.
Therefore, as long as you follow the recommended design pattern of
grabbing a connection from the pool whenever you need one, and then
returning it immediately after you are done (by calling
connection.close()), the validation query ensures that you never have to
deal with a broken connection yourself -- unless, of course, the database
goes down during the few milliseconds when you are performing your
transactions.
> Regards,
>
> Mark
>
Craig
> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@;apache.org]
> Sent: 07 November 2002 18:34
> To: Jakarta Commons Users List
> Subject: Re: [dbcp] Idle connecions
>
>
> On Thu, 7 Nov 2002, Keates, Mark wrote:
>
> > Date: Thu, 7 Nov 2002 12:52:50 -0500
> > From: "Keates, Mark" <[EMAIL PROTECTED]>
> > Reply-To: Jakarta Commons Users List <[EMAIL PROTECTED]>
> > To: Jakarta Commons Users List <[EMAIL PROTECTED]>
> > Subject: [dbcp] Idle connecions
> >
> > Hi,
> >
> > I'm looking into updating some servlet code to utilise dbcp.
> > >From reading the group (along with Tomcat-user) I'm unclear
> > on whether out-of-the box dbcp caters for handling:
> >
> > a) Idle connections - if an connection in the pool remains
> > idle for a configurable period then the connection is closed.
> > Therefore initially the pool has no connections until the
> > first request is made.
> >
> > b) Restarting of a database, e.g. Oracle shutdown immediate.
> > The pool should try and re-establish a broken connection (e.g.
> > for a configurable number of retries with a configurable wait period)
> > and then throw a 'connection unavailable' exception for the
> > servlet to deal with.
> >
> > If these features aren't available then can the existing
> > classes be easily extended to provide these features?
> >
> > Regards,
> >
> > Mark
>
> --
> To unsubscribe, e-mail: <mailto:commons-user-unsubscribe@;jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-user-help@;jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <mailto:commons-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-user-help@;jakarta.apache.org>
