GREAT, thanks Phil!!! I'm going to checkout the current trunk and updating pool code!!! Have a nice weekend!!! Simo
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]
