commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodney Waldhoff <>
Subject RE: DBCP tracking stale connections?
Date Tue, 10 Dec 2002 13:46:09 GMT
> > BasicDataSource currently doesn't expose testWhileIdle,
> > although if you look at how the other props are dealt with,
> > it wouldn't be difficult to expose it (a small change to
> > BasicDataSourceFactory and BasicDataSource is all that is
> > required).  I'd be happy to commit the patch if  you test
> > it first.

> Sounds good to me! A performance gain of 100% I'd gladly test a little
> for.

Unless all your queries are a simple as "select 1" the performance boost
will be substantially less than 100%, but testOnBorrow is a fairly
expensive option (but guarentees that the connection is valid when you
obtain it).

> I've got a few test situations running here and can do a stress
> test as well as a test whether it will keep running after 16 (or more if
> desirable) hours. The only database I have however is mysql.(Dunno if
> this is a problem?)

Great. I even wasn't thinking anything that elaborate.  I just wanted you
to test that the property is making its way from your XML configuration to
the instantiated pool (so I don't have to install and configure a new
tomcat instance to test the patch).

> Two questions about this though.
> 1. Is the rest of the package in a stable condition ATM?

It is used pretty widely in a variety of configurations.  As I mentioned,
the jdbc2pool stuff has never been part of a formal release, but it seems
stable as well.  (Behind the scenes, all of BasicDataSource,
PoolingDriver, PoolingDataSource, and Jdbc2PoolDataSource use or can use
GenericObjectPool from commons-pool so there's a substantial and important
portion of all that is shared)

> 2. Can you tell me what the inner workings of
> TestOnIdle are? I mean does it test when a connection has been idle for
> so and so many hours? Is this configurable?

GenericObjectPool supports an "evictor thread" that does this sort of
thing.  Here's a quote from the JavaDocs:

"Optionally, one may configure the pool to examine and possibly evict
objects as they sit idle in the pool. This is performed by an "idle object
eviction" thread, which runs asychronously. The idle object eviction
thread may be configured using the following attributes:

* timeBetweenEvictionRunsMillis indicates how long the eviction thread
should sleep before "runs" of examining idle objects. When non-positive,
no eviction thread will be launched.

* minEvictableIdleTimeMillis specifies the minimum amount of time that an
object may sit idle in the pool before it is eligable for eviction due to
idle time. When non-positive, no object will be dropped from the pool due
to idle time alone.

* testWhileIdle indicates whether or not idle objects should be validated
using the factory's PoolableObjectFactory.validateObject(java.lang.Object)
method. Objects that fail to validate will be dropped from the pool."


Roughly, here's what the evictor is doing:

  sleep for "timeBetweenEvictionRunsMillis"

  for the next "numTestsPerEvictionRun" connections {

    if "minEvictableIdleTimeMillis" is set {

       if this connection has been idle for more than
"minEvictableIdleTimeMillis", evict it


    if "testWhileIdle" {

       if this connection failes the validation query, evict it




In the cvs HEAD version, the heart of this is exposed as an evict() method
on the pool, which would allow you to come up with alternative strategies
for invoking it.

> > Alternatively, you should be able to use the "jdbc2pool" support via
> > Tomcat's JNDI.
> I don't really care which to use. DBCP is the Pool that is recommended
> in the Tomcat documentation (see
> The documentation on the link you provided about jdbc2pool seems to be a
> lot thinner.

As I said above, these all share a lot more than they don't (namely
commons-pool), but use whatever works for you and you feel comfortable
with.  (Certainly BasicDataSource is convienient within Tomcat).

> It works, the documentation however isn't entirely complete yet. For
> instance it doesn't mention a place where explanations of other
> configurational parameters might be sought. This would prevent people
> like me from asking these questions:)

The JavaDocs are probably the most complete documentation (and include
more than simple method descriptions), see
<> and
<> for the released versions,
for the latest versions.  Both should be fairly stable.

> P.S. Is it normal I see a lot of cvs commit mails in this list?

Yes.  You'll probably want to set up a filter.

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

View raw message