commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [DBCP] The plan for v2
Date Tue, 22 Mar 2011 18:48:21 GMT
On Tue, Mar 22, 2011 at 2:20 PM, Mark Thomas <markt@apache.org> 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
>

I would use a generic version of pool1 today!


> - fixing inconsistencies / oddities
>

I tried to address some of that in pool2 but we got bogged down in all sorts
of other issues, including API style. My main concern was the refactoring of
duplicate code.


> - 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
> - rename pool package to o.a.c.pool2
>  (in reality this would probably be a merge from POOL_FUTURE)
>

Why not just use pool2 trunk then? I guess you'll have to try and see.


> - 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'd hate to see all of the pool2 work tossed aside but I do like the
evolutionary approach of getting pool2, dbcp2 and Tomcat changing in
lockstep, one commit at a time. Right it sounds like you are saying that
pool2 is different enough from pool1 to be a big pain for dbcp2 and Tomcat.

Gary

>
> Mark
>
> > Min Java 5: +1!
> >
> > Gary
> >
> > On Tue, Mar 22, 2011 at 1:46 PM, Mark Thomas <markt@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-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
Thank you,
Gary

http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message