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 ? Rémy > > I'm +0 on this, FTR. > > -chris > >
