RE: JCA ConnectionPoolDataSource

[gianny DAMOUR <gi...@hotmail.com>]

Bruce Snyder wrote:

>The JDBC 3.0 spec requires a compliant JDBC driver to provide a
>connection pool implementation via the JDBC 3.0 API.
This is not how I have interpreted the JDBC 3.0 specifications.

Are we talking about the jdbc-3_0-fr-spec.pdf specifications?

My understanding is that a JDBC vendor provides an implementation of:
- DataSource;
- ConnectionPoolDataSource; or/and
- XADataSource.

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

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

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

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

>But first we need to determine if we really need a connection pool.
Based on my understanding of the specifications, one should need one. 
Excerpt of the "Connection Pooling" section:

"In FIGURE 11-1, the JDBC driver provides an implementation of 
ConnectionPoolDataSource that the application server uses to build and 
manage the connection pool."

Gianny

_________________________________________________________________
MSN Messenger 6 http://g.msn.fr/FR1001/866  : dialoguez en son et en image 
avec vos amis.

RE: JCA ConnectionPoolDataSource

[Jeremy Boynes <je...@coredevelopers.net>]

> From: Bruce Snyder [mailto:ferret@frii.com] 
> Sent: Sunday, September 14, 2003 8:38 PM

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

Geir did the initial checkin of the seed code - this is from there.

--
Jeremy

RE: JCA ConnectionPoolDataSource

[Bruce Snyder <fe...@frii.com>]

This one time, at band camp, gianny DAMOUR said:

My apologies for the delayed response.

gD>Bruce Snyder wrote:
gD>
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>
gD>Are we talking about the jdbc-3_0-fr-spec.pdf specifications?
gD>
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?

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

The Castor Project
http://www.castor.org/

Apache Geronimo
http://incubator.apache.org/projects/geronimo.html