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.
I agree. My current implementation uses Jakarta commons-pool, which provides a generic object pooler.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.
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.
