Rémy, On 3/29/18 9:30 AM, Rémy Maucherat wrote: > On Thu, Mar 29, 2018 at 3:15 PM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > >> Rémy, >> >> On 3/29/18 8:42 AM, Rémy Maucherat wrote: >>> On Thu, Mar 29, 2018 at 2:33 PM, Christopher Schultz < >>> ch...@christopherschultz.net> wrote: >>> >>>> Rémy, >>>> >>>> On 3/28/18 2:25 PM, Rémy Maucherat wrote: >>>>> Hi, >>>>> >>>>> In Tomcat, DBCP2 is missing the XA portion (all contained in a single >>>>> "managed" package). So at work I now got some people asking about that >>>>> removal, and that's always a bit annoying as they have to go to a >>>> separate >>>>> vanilla DBCP2 to get the functionality. Annoying sometimes. >>>>> >>>>> So it would be possible to add the classes in Tomcat (including the >>>>> javax.transaction to build, as that's the Tomcat way to deal with >> that), >>>>> even though the user would need to add its own transaction manager to >> do >>>>> anything with it. >>>>> >>>>> Should I now add it (only in 9/trunk) or instead leave things the way >>>> they >>>>> are ? Both work to be honest, it's just that I've been bitten by the >> "we >>>>> only ship 3/4 of DBCP and I didn't know it" bug. >>>> >>>> I've always wondered why we bother to package-rename DBCP2 and check-in >>>> the source into our svn repo (soon to be Git). Why not pull DBCP2 from >>>> source during the build and re-name it on the fly? >>>> >>>> Because that's what was done before Tomcat 8.0 and it's not done like >> that >>> now :) >>> Mark wrote this: >>> Switch to including Apache Commons DBCP via a package renamed svn >>> copy >>> rather than building from a source release for consistency with >>> other >>> Commons packages and to allow faster releases to fix DBCP related >>> issues. (markt) >>> >>> And you didn't complain then it seems. >> >> So we do it this way because I failed to speak-up? Unlikely. >> > > It was done in 8.0.6 with the justification I quoted above and I have to > assume that nobody complained. I was busy doing NIO2 stuff at that time > personally. That's all I can remember. > >> >> Anyhow, this seems like a "DBCP related issue" so we ought to be able to >> do a "faster release" by duplicating more code, then, eh? >> > > The rationale was probably: you can fix bugs without having to wait for a > DBCP release. I'm not certain this actually happened though. > > I actually have a question. There's also that *second* connection pool, > Tomcat JDBC, although it is more "external" as it is located inside the > modules. So reading the list of "pros" from its docs, it seems DBCP > addressed most (all ?) of them, except that it's still significantly > bigger. So what's the current benefits of Tomcat JDBC over Tomcat DBCP2 ? > Did anyone do benchmarks or anything ?
I believe Filip built that in response to the issues with DBCP at the time. I assume that benchmarks were done at the time proving the usefulness of the tomcat-pool over DBCP 1.x. I know of no new benchmarks. Sounds like fodder for an ApacheCon presentation. :) Tomcat-pool does have some features that DBCP2 still lacks (such as interceptors), which probably means that it serves a niche. I'm not sure how large that niche is. At some point, it probably makes sense to extract tomcat-pool from the Tomcat project and make it a separate entity. Probably not a TLP, but at least something that can be grabbed from source separately from Tomcat and used independently. Of course, you can already just grab tomcat-jdbc.jar and use it separately (right?) but we don't make it obvious how to do that (The build-tomcat-jdbc doesn't have a "description" attribute and so doesn't show up in ant -projecthelp). Perhaps the git-migration would be an opportunity to do that. -chris
signature.asc
Description: OpenPGP digital signature
