commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John McNally <>
Subject [dbcp] [patch] merge in jdbc2pool
Date Thu, 13 Jun 2002 18:16:53 GMT
I would like to merge most of the code in sandbox/jdbc2pool into dbcp. 
With the only condition that dbcp will be moved to the
project when/if it is approved.  As dbcp is proposed as one of the
projects to jumpstart this new project, I assume it is an easy condition
to meet.

Why does jdbc2pool fit into dbcp?

jdbc2pool is made up of two packages.  The first, jdbc2pool, contains
one public class that is a DataSource implementation.  It is similar in
architecture to BasicDataSource already in dbcp, though there are
considerable differences as well, so that it complements the existing
DataSources.  It uses pools from commons-pool as do the rest of the
connection pools in dbcp.  The other package implements the new
ConnectionPoolDataSource interface which is a replacement for Driver.
This package makes use of dbcp's prepared statement pooling.

The main difference between BasicDataSource and Jdbc2PoolDataSource is
the backend used to supply physical connections to the database.  Jdbc
driver vendors supply Driver and DataSource implementations that are to
be used by jdbc1 dependent applications.  The DataSource implementation
can also be used by jdbc2/3 applications, though the implementation by a
jdbc vendor typically does not include connection pooling. 
BasicDataSource uses a Driver implementation and wraps it in a
DataSource that does supply connection pooling.  Jdbc2 defines another
interface that a jdbc vendor should supply, ConnectionPoolDataSource
(CPDS).  The implementation of this interface is meant to be used by
third party connection pools.  Jdbc2PoolDataSource uses a CPDS as the
source of physical connections.

Other than this primary difference, of which many users could care less,
there are a few other differences.  Jdbc2PoolDataSource presents access
to many more of the backing commons-pool parameters to tune the
connection pool.  It allows multiple usernames to be used, these
multiple usernames can share a configuration, e.g. a single maximum
number of connections.  Or different usernames can be given a separate
allotment of connections.

The other package that was part of jdbc2pool was a CPDS implementation
that could be used to adapt a vendors Driver implementation to present a
CPDS frontend.  This is useful as it allows the Jdbc2PoolDataSource to
be used with a jdbc implementation that has not fully implemented the
later specifications.  

In the jdbc3 spec it is the jdbc vendor's responsibility to supply
PreparedStatement pooling, it is not required to do so.  Jdbc2 does not
define a protocol for PreparedStatement pooling.  The CPDS adapter
implementation does supply PreparedStatement pooling.  It uses the the
PreparedStatement pooling classes in dbcp to accomplish this.

I have posted the new classes at

There is a tarball of all the new source code as well as the the java
files for easy web viewing.  The patch file that is also located here
adds @deprecated flags to methods which implement methods that have been
deprecated in the interfaces, which might be useful regardless of the
decision on jdbc2pool.

I would ask that if the code is added to dbcp that I be given committer
status on dbcp.

john mcnally 

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message