On Tue, Mar 22, 2011 at 2:52 PM, Phil Steitz <phil.ste...@gmail.com> 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. > +1 > > Does the first item include replacing the wait/notify stuff with > j.util.concurrent primitives? > > 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 > > - 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 > I am fine with above, though I don't think there are any > incompatible changes yet in the POOL_1_X branch or dbcp trunk, so > steps 5 and 6 above are no-ops. I also don't want to be a stick in > the mud, but it would be great to close the handful of issues open > against POOL_1_X and cut a 1.5.5 before the copy so we could avoid > having to port fixes. I will cut the release if we can agree on the > fixes. Same holds for DBCP. A little concerted effort could get > 1.3.1/1.4.1 out before cutting the new branch. I am fine, though, > working these in parallel if that is what we want to do. > Detail: The next pool maintenance release will be 1.5.6; 1.5.5 is out. Release early, release often, a la XP :) Gary > > Phil > > 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 > > -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory
