A little backstory on the connection pooling mechanism I submitted to Struts
a while back:
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. So, I repackaged my code as org.apache.struts.*, and submitted it
to the list.
This is the way open source development is supposed to work, no? I had an
itch, I scratched it. I noticed others had the same itch, so I offered it
up.
Now, unbeknownst to me, the Turbine project over at java.apache.org also has
a connection pooling library with similar functionality. Maybe it's my
fault for not knowing this. Maybe it's the struts-dev folk’s fault (sorry
guys) for failing to mention that there is a connection pooling library in
Turbine over at java.apache.org. Maybe it's Apache's fault for not
providing a clear picture of what is available and where. Maybe it doesn't
matter anyway because I think my pool is better designed, easier to
maintain, or more feature rich than the existing one, in which case I think
it's up to the community to decide which implementation they'd like to use.
(And before we go off on a a holy war here, I'm not saying that I do think
that. I'm specifically not saying that one impl is better or worse than the
other. Not having looked at the Turbine stuff in detail, I'm in no position
to state that. I'm just saying that that is a valid position to take. It
could be wrong (in the eyes of the community) but it's not unreasonable.)
Jon's response to this, when brought up in a slightly different context, was
a bit off-putting:
> > Meanwhile, I do think there would be a lot of interest in a Jakarta
> > connection pool. In fact, someone has offered to donate one to Struts.
> > > < http://marc.theaimsgroup.com/?l=struts-dev&m=97967619230491 >
>
>Totally friggen lame.
>
>*All* of that code (and more) is already implemented in Turbine and can be
>used outside of the core "Turbine" system very easily.
If all of that functionality is available in Turbine, that makes it
*redundant*, not lame. Moreover, having poked around a bit in the Turbine
stuff (and granted, I didn't poke that hard or that long, so maybe I missed
it), it seems to me that not "all of that code is already implemented in
Turbine". Specifically, (a) I don't see that Turbine is doing any pooling
of PreparedStatements, which if you recall was the major itch I was trying
to scratch, (b) Turbine's Connection pool seems to require specific
references to TurbineDB--so that legacy code has to be retrofitted to work
with Turbine's pool, (c) Turbine's pool doesn't seem to support a
javax.sql.DataSource interface. Could Turbine's pool be modify to support
these things? Of course, but I wasn't aware of Turbine's pool when I first
submitted mine. Moreover, Jon's response doesn't make me feel like my
contribution is very welcome there.
Frankly, there seems to be some underlying Turbine vs. Struts politics here
that I don't want to get involved in. If you'd like to debate the merits of
one pooling implementation versus another, or to work to see the full suite
of functionality implemented in a single pooling library, or perhaps to
debate whether or not more than one pool implementation is warranted, then
let's do so. But I don't think a knee-jerk response like that does much
more than alienate potential developers.
I was going to segue this into a discussion of how a more modular
utility/services/library project or set of projects is warranted, but I see
that Morgan and Ted have already kicked that off in earnest, so I'll follow
up in that thread.
- Rod
-----Original Message-----
From: Steve Downey [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 07, 2001 4:23 PM
To: '[EMAIL PROTECTED]'
Subject: RE: What is Jakarta?
It may not be easier, but it's certainly more fun. And it often seems easier
to build to suit than to adapt something.
-----Original Message-----
From: Jon Stevens [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 07, 2001 3:24 PM
To: [EMAIL PROTECTED]
Subject: Re: What is Jakarta?
on 2/7/01 12:15 PM, "Morgan Delagrange" <[EMAIL PROTECTED]> wrote:
> My mistake, although stating that you have a database
> connection pool component does not imply that it is
> applicable outside of Turbine.
You could ask a very simple question:
"Is Turbine's Connection Pooling code available for use outside of Turbine?"
Oh wait, I forgot, it is easier to write a connection pool from scratch than
it is to ask a simple question.
:-(
-jon
--
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
<http://jakarta.apache.org/velocity/> && <http://java.apache.org/turbine/>
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
