commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Gaspar" <paulo.gas...@krankikom.de>
Subject RE: torque and my work on its connection pool.
Date Tue, 08 Jan 2002 22:09:51 GMT
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:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>


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