db-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@adeptra.com>
Subject Re: Hello
Date Thu, 09 May 2002 18:39:42 GMT
On 5/9/02 2:06 PM, "Rodney Waldhoff" <rwald@hotmail.com> wrote:

> Geir wrote:
>> "Ignacio J. Ortega" <nacho@siapi.es> wrote:
>>> Another nice addition to the starter set in the db could be
>>> commons-dbcp..
>> I agree, but when I suggested bringing poolman in to Jakarta, there was
>> strong opposition from the dbcp people...
> I'm probably one of those "dbcp people" you refer to.  I don't recall
> offering "strong opposition".
> I do see this note from John (a commons-sandbox/Jdbc2Pool "person", i
> suppose):
> http://nagoya.apache.org/eyebrowse/ReadMsg?listName=commons-dev@jakarta.apache
> .org&msgId=75929
> which raises some good points.

Certainly.  However, this isn't a technical argument.  It's a "preserve the
product" thing for me.
>> Maybe they've changed their minds?
> I've consistently maintained that my database pool concerns are:
> 1. That it provide a mechanism for "pluggable" pooling algorithms (ideally
> based upon a generic pooling mechanism)
> 2. That is support PreparedStatement pooling
> Other than that, I don't much care what the implmentation is, where it comes
> from, or who wrote it.  As yet DBCP seems to be the only pool that meets
> these criteria, and hence that's the tool I use and support.
> On a related note, I notice that in the above mentioned message, John wrote:
>> The code in sandbox/jdbc2pool uses the commons pool and DBCP's
>> PreparedStatement pool while attempting to implement the jdbc2
>> specification.  Geir and anyone else at jakarta who wants to work on a
>> connection pool, why not join me in finishing this?
> I guess I didn't catch that before.  John, how far apart are jdbc2pool and
> dbcp in this?  Does jdbc2pool support statement pooling?  Does jdbc2pool
> support JDBC3? What would have to change in dbcp to fully support JDBC2/3?
> I'd much rather have a smaller number of robust pools than a large number of
> pools each scratching and individual itch.  Let's scrap all of dbcp,
> jdbc2pool and poolman and start over if that's what it takes to overcome NIH
> issues.  I suspect none of these are that far apart.

You don't get it - Poolman has a huge user base.  Many companies (all I
regularly consult for, and they were using it before I showed up), the DOD,
etc, etc, etc.  If the mood is to just discard to start fresh with untested,
unused code, that's fine - Poolman can stay where it is.  History has
repeatedly shown the value and importance of mindshare and momentum.  Don't
discard that for technical superiority, as that can be added over time.

The point of bringing poolman is in support of one of the principles of the
ASF - to ensure that open source projects can survive their initial
developers.  In this case, the initial developer did the right thing in one
way, and got hung by it - he kept the # of committers to 1 (himself) because
of the LGPL and wanted the freedom.  That means we don't have to fight with
anyone for clear title to the code, but have to boostrap the developers.
That¹s the cost.

That said, with Poolman you get a *huge* commercial user base.  That means
that we can take advantage of the brand to incorporate good things created
here at Jakarta.  However, whatever is done has to be managed carefully to
keep things compatible and stable.


Geir Magnusson Jr.
Research & Development, Adeptra Inc.

View raw message