commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject RE: jdbc2pool
Date Tue, 15 Jan 2002 21:28:32 GMT
See intermixed.

On Tue, 15 Jan 2002, Waldhoff, Rodney wrote:

> Date: Tue, 15 Jan 2002 13:20:13 -0600
> From: "Waldhoff, Rodney" <rwaldhof@us.britannica.com>
> Reply-To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> To: "'commons-dev@jakarta.apache.org'" <commons-dev@jakarta.apache.org>
> Subject: RE: jdbc2pool
>
> > Hopefully the jdbc2pool code in the sandbox can
> > be used to spur a quick update of the DBCP code.
>
> +1
>
> 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
> (PoolingDriver/DriverManagerConnectionFactory)
> * You can make DataSource-generated Connections appear to come from a Driver
> (PoolingDriver/DataSourceConnectionFactory)
> * 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.
>

I can do this one, if you want.  It would make life easier on Struts users
so we can use DBCP as well.

This, of course, won't be the *only* possible way to layer together a
connection pool based on POOL and DBCP, but it will save someone having to
wire it together themselves.

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

Just out of curiousity, why is ConnectionPoolDataSource important to you?
At the application level, for instance, J2EE applications deal in terms of
javax.sql.DataSource implementations -- CPDS look like its only relevant
if you want to build XADataSource things for distributed transactions.

And, unfortunately, CPDS doesn't extend javax.sql.DataSource, so an app
has to choose one or the other API to talk to.

> > 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 can rip off the code we have in Tomcat to create a JNDI ObjectFactory
for DBCP-based connection pools.  It's pretty generic.

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

Craig



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