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 19:24:32 GMT
On 22/03/2011 18:52, Phil Steitz wrote:
> On 3/22/11 11:20 AM, Mark Thomas wrote:
> 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.
> +1
> Does the first item include replacing the wait/notify stuff with
> j.util.concurrent primitives?

Yes, in combination with the third item.

>> 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
> I am fine with above, though I don't think there are any
> incompatible changes yet in the POOL_1_X branch or dbcp trunk, so
> steps 5 and 6 above are no-ops.

Not quite no-ops. There will be some imports to rename but that should
be the limit of it.

> I also don't want to be a stick in
> the mud, but it would be great to close the handful of issues open
> against POOL_1_X and cut a 1.5.5 before the copy so we could avoid
> having to port fixes.  I will cut the release if we can agree on the
> fixes.  Same holds for DBCP.  A little concerted effort could get
> 1.3.1/1.4.1 out before cutting the new branch.

That makes sense to me. It also gives folks a chance to chime in with
their views on the plan.


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

View raw message