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:55:54 GMT
On Tue, Mar 22, 2011 at 2:52 PM, Phil Steitz <phil.steitz@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 <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
> >
> >
>
>
> ---------------------------------------------------------------------
> 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