commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John McNally <jmcna...@collab.net>
Subject Re: torque and my work on its connection pool.
Date Wed, 09 Jan 2002 00:41:25 GMT
"Craig R. McClanahan" wrote:
> 
> 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
> 


I would argue that this class belongs with the connection pool.  A jdbc2
pool should be ready to deploy within a jndi service provider.  

john mcnally

--
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