commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Waldhoff, Rodney" <>
Subject RE: jdbc2pool
Date Tue, 15 Jan 2002 19:20:13 GMT
> Hopefully the jdbc2pool code in the sandbox can
> be used to spur a quick update of the DBCP code.


Just to make sure we're on the same page, a note on the way DBCP is set up:

DBCP is comprised of three layers.  From front to back:

1) A "client-facing" layer that can make the pool appear to be a DataSource
(for JDBC2) or Driver (for DriverManager-based stuff)

2) A "pooling" layer that pools Connections (and optionally
PreparedStatements) using an arbitrary pool (that implements the
commons-pool interface)

3) A "connection factory" layer that creates or obtains connections.  This
can be based upon a DataSource or the DriverManager.

To set up a pool, you essentially glue together one implementation of each
layer.  Ignoring the pooling layer for a second, you can glue together the
"factory" and the "interface" in any of the following ways:

* You can access unpooled Driver-based connections via a pooling Driver
* You can make DataSource-generated Connections appear to come from a Driver
* You can access unpooled DataSource-based connections via a pooling
DataSource (PoolingDataSource/DataSourceConnectionFactory)
* You can make DriverManager-generated Connections appear to come from a
DataSource (PoolingDataSource/DriverManagerConnectionFactory)

Re the DBCP/JDBC2 incompatibilities:

> 1. Should be deployable using standardized tools which will 
> assume a no argument constructor and bean getter/setters 
> for configuration

This should be easy enough to patch into DBCP, and worth the trouble. You'll
notice that a revision to the configuration of DBCP has been on the TO DO
list for while.

> 2. Jdbc2 driver implementation will supply a CPDS that should be used 
> when pooling connections.  DBCP does not use this interface instead it 
> pools the older style Connection objects.

I'm not sure I follow you here.  If you've got a DataSource that pools the
connections, what's left for the "pool" package to do?  If your DataSource
doesn't pool connections, isn't Connection the right object to pool?

> 3. Some Jndi interface which should be implemented in a Jdbc2 
> product are left for the individual applications to complete.

I'm not sure specifically what you're referring to (the unsupported methods
in PoolingDataSource?), but I suspect those should be easy enough to add to
the base implementation.

> I am unsure of the DBCP developers intentions

For my part, there are a handful of features that I require of connection
pooling implementation:

1) The pooling algorithm itself (how many instances to store, when to evict,
how to determine what to evict, etc.) should be pluggable.  Preferably the
DBCP would leverage a "generic" pooling implementation to achieve this,
since the issues are largely the same.

2) The DBCP should support pooling of PreparedStatements.  This has an
enormous impact in the production applications I work with, and anything
that doesn't support it is essentially unusable for my needs.

3) The DBCP should support (but not require) old-style JDBC interactions
(i.e., DriverManager.getConnection/Connection.close) since I've got too much
legacy code based upon that style of JDBC interaction.  And whether they're
right or not, many developers are going to find that easier to work with
than JNDI-based configuration anyway.  (It's simple to create a thin Driver
that wraps a DataSource anyway, so this should be easy to provide.)

Beyond that I don't have a strong opinion on the implementation.

You're suggesting a new set of requirements, largely that DBCP be fully
JDBC2-compliant.  I welcome that, and indeed there are already steps in that
direction in the current DBCP code base.

I don't see any major incompatibilities between those requirements.  If you
agree, why not work to produce a common component that supports both?

 - Rod

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message