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 <ma...@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-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
