commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: torque and my work on its connection pool.
Date Tue, 08 Jan 2002 21:12:53 GMT

On Tue, 8 Jan 2002, John McNally wrote:

> Date: Tue, 08 Jan 2002 12:56:56 -0800
> From: John McNally <>
> Reply-To: Jakarta Commons Developers List <>
> To:
> Subject: torque and my work on its connection pool.
> I guess there has been some discussion on whether commons should come up
> with an alternative to torque or whether torque should be moved to
> commons.  I am unclear on why torque is unsatisfactory due to its
> current location.  I will have read up on that discussion, if anyone has
> useful pointers to the discussion in the archive that would be great,
> otherwise I will find them.  But I will take a moment to describe my
> work on updating torque as this work seems to have come up in an
> validation framework thread.

I'm not touching this one ... the entertainment value of all the rhetoric
went down about a hundred messages ago :-).

> Torque currently relies on an internal connection pool.  I would like
> that this reliance dependence be broken, so i looked at the jdbc2 api
> regarding connection pooling and decided to adopt it for use in torque
> as that should maximize the number of pools available.  So for torque
> the part of the jdbc2 api that is relevant is
> 1.  The connection is retrieved through DataSource.getConnection
> 2.  The connection is returned (or disposed of) through
> Connection.close()
> It is possible the commons dbcp package meets these requirements and so
> it could be used with torque.

It should be possible to do this.

>  I looked at dbcp and it did not seem to
> be jdbc2 compliant.

In what respects?  IIRC, JDBC 2.0 compatibility was definitely one of the
design goals.

>  In looking at the pool it had many classes, so the
> design was difficult for me to get a handle on.  I opted instead to make
> torque's connection pool jdbc2 compliant.  As torque's cp was two
> classes this seemed like a much easier task.

It's definitely true that DBCP and POOL are hard to understand -- think of
them as a toolkit for building connection pools, and it makes more sense.
In particular, I did an implementation of a DataSource for Tomcat 4 --
it's in the head branch of the "jakarta-tomcat-4.0" repository, in file:


This was done in the form of a JNDI resource factory, but the
JNDI-specific stuff could be ripped out pretty easily (by changing the
configuration items to JavaBeans properties).  It might be useful for you.

> Actually it turned out to not be that simple (but it is still two
> classes), so in hindsight maybe I should have taken the additional time
> to figure out the commons dbcp and then try to become a member of the
> commons and push through an upgrade of the dbcp to the latest jdbc api.
> Are the maintainers of the commons dbcp interested in updating their
> pool to be jdbc2 (or 3) compliant?  I think they would be well served by
> looking at the work I have done on torque's dbcp.  I will post a link to
> the files if they are interested.  I created an adapter for use with
> jdbc drivers that do not implement the latest api that would likely be
> useful if and when the commons dbcp was updated.

I'd definitely be interested in seeing what you did.  Maybe we can add a
class to DBCP that is a little easier to set up, and serve everybody's
needs (including Torque and Tomcat).

> john mcnally

Craig McClanahan

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

View raw message