On 4/23/11 2:24 PM, Gary Gregory 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. We need to make whatever other API changes we are going to make for the foreseeable future in 2.0 before cutting a 2.0 release. There are also quite a few issues requiring behavior change / definition that we need to resolve for 2.0. Just "generifying" is not enough. We need to think carefully about the 2.0 APIs for [pool] and [dbcp] - both syntax and semantics. Given the extent of reuse of these components, we can't afford to repeatedly break compatibility.
Phil > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
