On 02/08/2013 21:17, Michael-O wrote: > Am 2013-08-02 11:43, schrieb Mark Thomas: >> Michael-O <1983-01...@gmx.net> wrote: >>> Am 2013-08-01 22:59, schrieb Mark Thomas: >>>> If you'd like early sight of Tomcat 8 and an opportunity to >>> contribute >>>> to Tomcat development, the release vote has now opened for the first >>>> Tomcat 8 release candidate. >>>> >>>> Features include: >>>> -[...] >>>> - Update to DBCP2 (now includes JMX monitoring) >>> ^^^^^ >>> Why if we do have the wonderful Tomcat JDBC Pool? >> >> 1. Choice (we ship both). >> 2. Features (DBCP covers more edge cases). >> 3. Maintainability. There is more chance of a DBCP fix at the moment. >> That should change when Filip returns. >> 4. Performance they should be much closer but I suspect Tomcat JDBC >> will be faster (those edge cases again). > > According to Apache's JIRA DBCP2 is still in the works
The bulk of the work was in Pool 2 and that has been complete for a while. There are some discussions about further simplification of the Pool 2 API but the core pooling code is ready and is unlikely to change. The work to convert DBCP to use Pool 2 has been completed. DBCP currently has a number of open bugs and enhancement requests and that is holding up a formal release as a number of them are likely to trigger API changes both in Pool 2 and DBCP 2. In short, the core of DBCP2 is ready to go but the API is not stable. Getting it into the Tomcat 8 RC's is part of getting feedback to help stablise the API. > whereas Tomcat > JDBC Pool already works quite well. For some users yes. As I said previously, it does not cover as many edge cases as DBCP does. > If so, I would favor the first > option and make Tomcat JDBC Pool the default. Anyway DBCP2 will be a > breaking change for DBCP 1.x users. What makes you say that? I can't think of any configuration changes in DBCP2 so far that would cause breakage (although I could be wrong). > Why not go the extra mile with > Tomcat JDBC Pool and use that. It is (still) a one line configuration change to switch between the two. Personally, I'm not happy with JDBC Pool as the default - primarily because it is essentially supported by a single committer. It hasn't built up a development community yet. DBCP has that development community and is less dependent on a single committer. >>> Can't we get rid of that relic? >> >> We could but I would not support such a move. (Relic? Hardly.) > > I consinder it as a relic. Tomcat JDBC Pool's site even states that DBCP > was written in ancient times withou multithreading in mind. Pre Java 5 > and so forth. That is true of DBCP 1. It does not apply to DBCP 2. > From my point of view, I have achieved tremendous improvements in our > apps with Tomcat JDBC Pool and even found several bugs which would not > have been possible with DBCP. Great. You are free to continue using it. It will continue to be part of Tomcat 8 in the same way it is part of Tomcat 7. Getting those same performance improvements for users that need / want DBCP is a primary driver for Pool 2 and DBCP 2. Ultimately, I'd like to see the code bases converge but that is probably an optimistic goal for a number of reasons. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
