All,
This may be jumping the gun just a little bit, but I've got external
deadlines that are putting pressure on me to get this resolved.
The back story, for those who haven't heard it:
A couple of months ago, at the company I work for we ran into problems with
the connection pooling implementation within the commercial product we were
using. Specifically, (a) the pool itself was buggy and (b) the pool
implementation made it difficult for us to pool PreparedStatements and the
parse rate of unpooled PreparedStatements within the database was becoming a
bottleneck to application performance. For this reason I put together a
Connection/PreparedStatement pooling implementation that met our needs.
Completely independently, I noticed the Struts project on
jakarta.apache.org, started to poke around a bit, and subscribed to
struts-dev and struts-user. I noticed that Struts had a basic connection
pooling implementation. I also noticed several requests on struts-dev and
struts-user looking to expand the functionality on the Struts connection
pool. Many of the features (in fact all of the features) that were being
asked for were/are features of the Connection/PreparedStatement pool I put
together. Noting that there is nothing particularly proprietary about the
connection pooling mechanism I put together, I repackaged my code as
org.apache.struts.*, and submitted it to the list.
Since there is at least one other Java-based connection pooling
implementation available in the Apache world, that opened up a big can of
worms. Actually, I'd like to think of that as a Good Thing, since that's at
least a small part of what led us to here.
In any event, I have a demonstrated need for a connection pooling library
that supports (in addition to the basic configurable connection pooling, of
course):
a) PreparedStatement pooling
b) a pseudo-Driver interface
c) a DataSource interface
The connection pooling implementation I submitted to struts a while back
supports these features, and is based upon code that performs quite well for
us in a high-traffic (top 100 ;)), database-intensive, production
environment. I've placed the source "jar-ball", and a couple of links to my
original struts posts at http://www.webappcabaret.com/rwald/dbcp/. If you
are interested, feel free to poke around.
A few of comments on that bundle:
1. Everything is packaged as org.apache.struts.*. I fully expect that to
change, but I don't know what to, so I just left it as is for now.
2. The database connection pool sort of assumes a simple but generic object
pooling library (that I packaged as org.apache.struts.util.pool.*) which in
turn assumes a "generic" CursorableLinkedList (that I packaged as
org.apache.struts.util). I stand by the notion that the connection pool is
nothing more than an extension to a generic pooling mechanism, but I'm
willing to make it stand-alone at first, and refactor to use the common
object pooling library whenever we reach consensus on that.
3. There is no build.xml, because it worked as-is with an unmodified struts
build.xml. Nothing fancy is required, straight javac and javadoc work fine.
4. There is a small example of how to use it in one of the linked posts.
The javadoc comments have some additional information as well.
As I mentioned above, we've got a new major release coming up that I'd like
to roll the Apache connection pooling module into, and there are some
additional features I'd like to add to the existing pool implementation
(optionally tracking the number of connections borrowed by a thread at one
time, for example). Ideally the Apache DBCP module will come together in
time for me do this, so this email is intended to jump-start that process.
I'm not married to this implementation (although we've been pretty happy
with it so far). I'd be happy to use a different starting point if someone
has one they'd like to offer up, or to integrate with other implementations
in the short or long run. I just need some kind of connection pool that
supports the three features mentioned above, and I'd like it sooner rather
than later.
Questions, comments or complaints are welcome. I specifically invite input
on:
i. Do others find this to be a reasonable starting point?
ii. How should this be packaged?
iii. What's next? If others have mods they'd like to suggest, I could
update the JAR directly, or move it all to some Apache CVS or to SourceForge
for the time being.
- Rod
