commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simonetrip...@apache.org>
Subject Re: [DBCP] The plan for v2
Date Sat, 23 Apr 2011 21:52:43 GMT
Hi Gary,
my strong +1 on this, that's way we agreed on resetting the trunk (and
I started working to restore generics :P)
Thanks for your feedback!!!
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Sat, Apr 23, 2011 at 11:24 PM, Gary Gregory <garydgregory@gmail.com> wrote:
> I'd like to think this reset should let us get to see a release with
> generics sooner rather than later. I'm all for releasing early for
> generics and moving on from three.
>
> Gary
>
> On Apr 23, 2011, at 12:14, Phil Steitz <phil.steitz@gmail.com> wrote:
>
>> 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
>>
>
> ---------------------------------------------------------------------
> 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