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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
