commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
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 <jmcnally@collab.net>
> Reply-To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> To: commons-dev@jakarta.apache.org
> 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:

  catalina/src/share/org/apache/naming/factory/DbcpDataSourceFactory.java

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:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message