commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: [DBCP] The plan for v2
Date Tue, 22 Mar 2011 18:20:55 GMT
On 22/03/2011 17:58, Gary Gregory wrote:
> Hi Mark and all:
> It's good to hear someone is thinking about moving forward!
> pool2 trunk seems to me to be highly volatile based on having worked some in
> pool2.
> I've read opinions here going back and forth as to how to solidify the API
> or even go /back/ to the pool1 style before moving forward again.
> I think time would be better spent solidifying pool2. Time spent matching
> dbcp2 to pool2 could be a waste because, to me, pool2 feels like a moving
> target ATM.

pool2 is a moving target because a lot of the re-factoring has been an
academic exercise. Having a clear end user for this (Tomcat -> DBCP ->
POOL) should provide the direction necessary to solidify pool2. I don't
mind working with a moving target as long as it is moving towards a
clear goal. That goal for me is:
- Java 5 / generics
- fixing inconsistencies / oddities
- improved performance on DBCP in multi-core servers.

It would certainly make starting dbcp2 a whole lot easier if most of the
pool2 re-factoring had not taken place. I think we made a mistake in not
pushing forward with DBCP and POOL in parallel. That said, I like a lot
of the pool2 changes and don't want to throw them away.

What do folks think to the following:
- move pool trunk to a POOL_FUTURE branch
- restore pool trunk to a copy of the POOL_1_X branch
- rename pool package to o.a.c.pool2
  (in reality this would probably be a merge from POOL_FUTURE)
- rename dbcp packages to o.a.c.dbcp2
- get pool2 and dbcp2 working together
- get Tomcat trunk working with dbcp2
- go through the POOL_FUTURE changes one at a time:
  - merging it into pool2 trunk
  - updating dbcp2 trunk if necessary
  - testing updated dbcp2 with Tomcat
  - if a POOL_FUTURE change breaks DBCP/Tomcat integration in a way that
can't easily be fixed skip that change and leave it in POOL_FUTURE


> Min Java 5: +1!
> Gary
> On Tue, Mar 22, 2011 at 1:46 PM, Mark Thomas <> wrote:
>> Don't let the title get your hopes up. I don't have one yet, at least
>> not a complete one.
>> One of the primary driver for pool2 was to make use of
>> java.util.concurrent for the pool implementation and significantly
>> improve DBCP performance on multi-core systems (re-using ideas where we
>> can from Tomcat's jdbc-pool). I'm at the point where I have some time to
>> work on this.
>> My very outline plan was as follows:
>> a) get DBCP working with pool2
>> b) run the jdbc-pool performance tests to see how much ground we need to
>> catch up
>> c) improve the pool2 implementation until we get somewhere close to
>> jdbc-pool
>> a) is non-trival and is really the focus of this e-mail.
>> Issue 1
>> =======
>> DBCP isn't going to be able to use pool2 without some major re-factoring.
>> My solution is:
>> - copy current dbcp trunk to a branch
>> - rename o.a.commons.dbcp to o.a.commons.dbcp2
>> - update dependencies from pool to pool2
>> - get it working
>> Issue 2
>> =======
>> DBCP also ships with the o.a.commons.jocl package.
>> There have been no jocl related questions on the users list since 2007.
>> To prevent clashes between dbcp1 and dbcp2 I propose to simply drop JOCL
>> support in dbcp2.
>> Issue 3
>> =======
>> Minimum Java version.
>> Supporting multiple JDBC API versions is a nuisance. I propose switching
>> to a jdbc-pool style proxy approach. I also propose a minimum Java
>> version of 5 to align with pool2.
>> Issue 4
>> =======
>> Will the new dbcp work with Servlet containers?
>> There were some concerns in this area with the pool2 re-factoring. This
>> needs to be tested but my turn out to be a non-issue.
>> I think these 4 issues need to be resolved before there is a pool2 or
>> dbcp2 release.
>> Assuming there are no objections, I plan to start committing along these
>> lines in the next couple of days.
>> Mark
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

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

View raw message