See comments below.
On Wed, 28 Mar 2001, Waldhoff, Rodney wrote:
> Here's the actual DBCP package proposal, as discussed earlier. I thought we
> could kick it around a little bit before submitting a real proposal.
>
> It relies upon the other three bundles.
>
> For the time being, the package can be found in the bundle at
> http://www.webappcabaret.com/rwald/commons/. I'll move it into the sandbox
> when I get access.
>
> I've left the same set of initial committers as in Ted's example proposal.
>
> Comments?
>
> - R.
>
> ---------------------------------------------------------------------
> Proposal for Database Connection Pool Package
> [Revision: $Id:$]
>
> (0) Rationale
>
> Many Jakarta products support interaction with a relational database.
> Creating a new connection for each user can be time consuming
> (often requiring multiple seconds of clock time), in order to
> perform a database transaction that might take milliseconds.
> Opening a connection per user can be unfeasible in a publicly-hosted
> Internet application where the number of simultaneous users can
> be very large. Accordingly, developers often wish to share a "pool"
> of open connections between all of the application's current users.
> The number of users actually performing a request at any given time
> is usually a very small percentage of the total number of active
> users, and during request processing is the only time that a
> database connection is required. The application itself logs into
> the DBMS, and a handles any user account issues internally.
>
> There are several Database Connection Pools already available, both
> within Jakarta products and elsewhere. A Commons package would give
> committers an opportunity to coordinate their efforts to create and
> maintain a efficient, feature-rich package under the ASF license.
>
> (1) Scope of the Package
>
> The package shall create and maintain a database connection pool
> package written in the Java language to be distributed under the ASF
> license. The package shall be available as a pseudo-JDBC driver and
> via a DataSource interface. The package shall also support multiple
> logins to multiple database systems, reclamation of stale or dead
> connections, testing for valid connections, PreparedStatement
> pooling, and other features.
>
> (1.5) Interaction with Other Packages
>
> Subclasses of the package should also be able to be configured
> via an external file (e.g. Turbine), and expose its status,
> exceptions, or other events to an external logging system (e.g.
> Log4).
>
> (2) Identify the Initial Source for the Package
>
> The initial codebase was contributed by Rodney Waldhoff from a
> working project and can be distributed under the Apache license.
>
> (2.1) Identify the Base Name for the Package
>
> org.apache.commons.dbcp
>
> (3) Identify any Jakarta-Commons Resources to be Created
>
> (3.1) Mailing List
>
> Until traffic justifies, the package will use the Jakarta-Commons
> list for communications.
>
> (3.2) CVS Repositories
>
> For the time being, the package will use a root branch of the
> Jakarta-Commons CVS.
>
> (3.3) Bugzilla
>
> The package should be listed as a component of under the
> Jakarta-Commons Bugzilla entry.
>
> (3.4) Jyve FAQ (when available)
>
> commons-dbcp
>
> (4) Initial Set of Committers
>
> Morgan Delagrange
> Geir Magnusson Jr.
> Craig R. McClanahan
> Rodney Waldhoff
> David Weinrich
> ---------------------------------------------------------------------
>
One of the JavaBeans specification rules that I tend to rely on heavily is
the existence of a no-arguments constructor (so that objects can be
instantiated dynamically). Generally, that means you would need property
setters for things that would otherwise be configured through constructor
parameters.
For a DBCP, this is important (to me, at least :-) in the following
scenarios:
* In Struts, I want to be able to configure a DBCP pool implementation
using Digester, when processing a <data-source> element.
* In Tomcat 4.0, I want to be able to configure a resource factory,
when processing the <Resource> element in the server.xml file,
so that web applications can access it via the JNDI initial context
that Tomcat provides, in a manner compatible with the J2EE spec's
requirements.
In both cases, it would be nice if I could use the
org.apache.commons.dbcp.PoolingDataSource class like this, but in the
current design it's not possible.
One option, I suppose, would be to write a wrapper of my own that conforms
to these requirements (and includes a "driver name" property so it can
preconstruct an object pool with the appropriate characteristics). Does
that sound like a rational approach?
Craig
