geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Snyder <>
Subject RE: JCA ConnectionPoolDataSource
Date Mon, 15 Sep 2003 03:37:38 GMT
This one time, at band camp, gianny DAMOUR said:

My apologies for the delayed response.

gD>Bruce Snyder wrote:
gD>>The JDBC 3.0 spec requires a compliant JDBC driver to provide a
gD>>connection pool implementation via the JDBC 3.0 API.
gD>This is not how I have interpreted the JDBC 3.0 specifications.
gD>Are we talking about the jdbc-3_0-fr-spec.pdf specifications?
gD>My understanding is that a JDBC vendor provides an implementation of:
gD>- DataSource;
gD>- ConnectionPoolDataSource; or/and
gD>- XADataSource.

My point was that the spec states that the JDBC vendor must provide
the ConnectionPoolDataSource. Yes, the app server needs to provide
an implementation to actually manage the list of pooled Connection
objects and that this requirement may lessen our work. However,
after re-reading the spec, It appears that little has changed other
than the requirement of the ConnectionPoolDataSource.

gD>These implementations - on top of a standard JDBC driver - are packaged as
gD>resource adapters by a JDBC vendor and deployed by an application server as
gD>non-cci interfaces via a standard RAR file.

Yes, this is correct.

gD>An application server uses the hooks provided by a PooledConnection in order
gD>to maintain a pool of physical connections. It also provides a uniform view
gD>to the client - a DataSource view - by implementing a DataSource, which
gD>delegates the creation of physical connections to a
gD>ConnectionPoolDataSource. This DataSource performs the bookkeeping of the
gD>logical connections handed over to clients.

Yes, this is correct as well.

gD>I agree that some JDBC vendors provide a connection pool implementation,
gD>however, it is not covered by the specifications I have here.

I misspoke and your analysis is correct.

gD>>If it is necessary to provide a pool, we should consider reusing
gD>>something already available at Apache rather than building our own
gD>>implementation. There's DBCP from Jakarta Commons that provides a pool of
gD>>java.sql.Connection objects and there's Pool also from Jakarta Commons
gD>>that is a generic object pooler.
gD>I agree. My current implementation uses Jakarta commons-pool, which provides
gD>a generic object pooler.

Great. IMO, I think we should compare the InstancePool to the Jakarta
Commons Pool. I'm apt to think that we'd get a more mileage out of
the Commons Pool. OTOH, the InstancePool is already there and being
used in Geronimo.

I notice that Geir checked this in and he is a committer for the
Commons Pool project. I wonder why he didn't just use Pool? Geir,
if you're out there, can you shed some light on the reasons for
this decision?

perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'

The Castor Project

Apache Geronimo

View raw message