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
