On Apr 23, 2011, at 18:43, Phil Steitz <[email protected]> wrote:
> 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 Sounds good but that's a lengthy process. Would it be possible to generify in the 1.x world. In a 1.6 for example? Gary >> 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
