commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [DBCP] The plan for v2
Date Sat, 23 Apr 2011 16:14:08 GMT
On 4/23/11 8:07 AM, Simone Tripodi wrote:
> GREAT, thanks Phil!!!
> I'm going to checkout the current trunk and updating pool code!!!
> Have a nice weekend!!!
> Simo

Great!  Remember to update changes.xml in trunk with references to
issues as you bring things over.  For now, let's just make the
generification changes (i.e., hold off on property name and
mutability changes).  I will start working on dbcp, first attacking
the real issues against 1.x and then getting compilation against the
new pool to work in trunk.

Phil
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Sat, Apr 23, 2011 at 5:04 PM, Phil Steitz <phil.steitz@gmail.com> wrote:
>> On 3/22/11 11:20 AM, Mark Thomas wrote:
>>> 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
>> Done.
>>
>> Phil
>>> - 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
>>>
>>> Mark
>>>
>>>> Min Java 5: +1!
>>>>
>>>> Gary
>>>>
>>>> On Tue, Mar 22, 2011 at 1:46 PM, Mark Thomas <markt@apache.org> 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: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message