You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by John McNally <jm...@collab.net> on 2002/01/08 21:56:56 UTC
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.
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. I looked at dbcp and it did not seem to
be jdbc2 compliant. 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.
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.
john mcnally
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: torque and my work on its connection pool.
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Tue, 8 Jan 2002, John McNally wrote:
> Date: Tue, 08 Jan 2002 17:36:22 -0800
> From: John McNally <jm...@collab.net>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: Re: torque and my work on its connection pool.
>
>
> > >
> > > 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.
> >
>
>
> A few more points/questions about this object factory. It seems it
> resets the pool each time the pool is requested from jndi. My
> understanding is the pool should be setup and deployed into jndi. Then
> when a class needs a connection it can request the pool from jndi and
> get a connection. It would seem if this ObjectFactory were used in this
> manner. The pool would always be starting from scratch.
>
You probably noticed a FIXME comment about this in the source ...
> I guess this factory is used in a different way?
>
In the current Tomcat code, the factory is initially bound to the JNDI
name -- but, the first time it's actually used, the returned data source
is bound in its place. That way, the pool is created only once, without
the factory itself having to worry about it.
I'm still studying whether that is the actual intent of the J2EE platform
specs w.r.t. object factories -- it may turn out that you're really
supposed to get a new object each time (although you can still do this
around a single "real" connection pool).
> john mcnally
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: torque and my work on its connection pool.
Posted by John McNally <jm...@collab.net>.
> >
> > 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.
>
A few more points/questions about this object factory. It seems it
resets the pool each time the pool is requested from jndi. My
understanding is the pool should be setup and deployed into jndi. Then
when a class needs a connection it can request the pool from jndi and
get a connection. It would seem if this ObjectFactory were used in this
manner. The pool would always be starting from scratch.
I guess this factory is used in a different way?
john mcnally
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: torque and my work on its connection pool.
Posted by John McNally <jm...@collab.net>.
"Craig R. McClanahan" wrote:
>
> On Tue, 8 Jan 2002, John McNally wrote:
>
> > Date: Tue, 08 Jan 2002 12:56:56 -0800
> > From: John McNally <jm...@collab.net>
> > Reply-To: Jakarta Commons Developers List <co...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: torque and my work on its connection pool.
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Tue, 8 Jan 2002, John McNally wrote:
> Date: Tue, 08 Jan 2002 12:56:56 -0800
> From: John McNally <jm...@collab.net>
> Reply-To: Jakarta Commons Developers List <co...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: torque and my work on its connection pool.
Posted by Paulo Gaspar <pa...@krankikom.de>.
> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> Sent: Tuesday, January 08, 2002 11:03 PM
>
> ...
>
> > Ahh, you're giving away all my secrets! (The Javadocs Paulo points at
are
> > where I figured out what to do for the Tomcat implementation :-).
> ...
I had the same problem when I used it. =;o)
Now I built my own monster.
Have fun,
Paulo Gaspar
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: torque and my work on its connection pool.
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Tue, 8 Jan 2002, Paulo Gaspar wrote:
> Date: Tue, 8 Jan 2002 23:09:51 +0100
> From: Paulo Gaspar <pa...@krankikom.de>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>,
> paulo.gaspar@krankikom.de
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: RE: torque and my work on its connection pool.
>
> I am no DBCP commiter, but the class to use in DBCP is quite obvious:
> org.apache.commons.dbcp.PoolingDataSource
> It implements DataSource.
>
> You just have to look at the obvious place:
> \jakarta-commons\dbcp\src\java\org\apache\commons\dbcp\package.html
>
> Which is the HTML source for the Javadoc documentation of package
> org.apache.commons.dbcp
>
> It has a how-to-use Q&A with just the code sample you need:
>
> GenericObjectPool connectionPool = new GenericObjectPool(null);
> DriverManagerConnectionFactory connectionFactory = new
> DriverConnectionFactory("jdbc:some:connect:string",null);
>
> PoolableConnectionFactory poolableConnectionFactory = new
> PoolableConnectionFactory(connectionFactory,connectionPool,null,null,false,t
> rue);
>
> PoolingDataSource dataSource = new PoolingDataSource(connectionPool);
>
Ahh, you're giving away all my secrets! (The Javadocs Paulo points at are
where I figured out what to do for the Tomcat implementation :-).
>
> Have fun,
> Paulo Gaspar
>
Craig
> > -----Original Message-----
> > From: jmcnally@krankikom.de [mailto:jmcnally@krankikom.de]On Behalf Of
> > John McNally
> > Sent: Tuesday, January 08, 2002 9:57 PM
> > 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.
> >
> > 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. I looked at dbcp and it did not seem to
> > be jdbc2 compliant. 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.
> >
> > 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.
> >
> > john mcnally
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: torque and my work on its connection pool.
Posted by Paulo Gaspar <pa...@krankikom.de>.
I am no DBCP commiter, but the class to use in DBCP is quite obvious:
org.apache.commons.dbcp.PoolingDataSource
It implements DataSource.
You just have to look at the obvious place:
\jakarta-commons\dbcp\src\java\org\apache\commons\dbcp\package.html
Which is the HTML source for the Javadoc documentation of package
org.apache.commons.dbcp
It has a how-to-use Q&A with just the code sample you need:
GenericObjectPool connectionPool = new GenericObjectPool(null);
DriverManagerConnectionFactory connectionFactory = new
DriverConnectionFactory("jdbc:some:connect:string",null);
PoolableConnectionFactory poolableConnectionFactory = new
PoolableConnectionFactory(connectionFactory,connectionPool,null,null,false,t
rue);
PoolingDataSource dataSource = new PoolingDataSource(connectionPool);
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: jmcnally@krankikom.de [mailto:jmcnally@krankikom.de]On Behalf Of
> John McNally
> Sent: Tuesday, January 08, 2002 9:57 PM
> 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.
>
> 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. I looked at dbcp and it did not seem to
> be jdbc2 compliant. 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.
>
> 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.
>
> john mcnally
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: torque and my work on its connection pool.
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 1/8/02 1:21 PM, "Randy Speh" <rw...@yahoo.com> wrote:
> I do not work on the commons code but have been
> looking at Torque's JDBC 2 compliance pretty closely
> in the jdbc2pool packages. I would appreciate it if
> you could provide a link to your latest work.
>
> Thanks,
> Randy Speh
I believe this is it...
<http://cvs.apache.org/viewcvs.cgi/jakarta-turbine-torque/proposals/jdbc2poo
l/org/apache/torque/jdbc2pool/?only_with_tag=JDBC2POOL_BRANCH>
-jon
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: torque and my work on its connection pool.
Posted by Randy Speh <rw...@yahoo.com>.
--- John McNally <jm...@collab.net> wrote:
> 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.
>
> john mcnally
I do not work on the commons code but have been
looking at Torque's JDBC 2 compliance pretty closely
in the jdbc2pool packages. I would appreciate it if
you could provide a link to your latest work.
Thanks,
Randy Speh
__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>