On 29/03/18 14:39, Christopher Schultz wrote: > 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: >>> 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: >>>>> 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? So we can release Tomcat with the latest DBCP2 and POOL2 sources without having to wait on Commons to produce a release. I find the Commons release process a pain to navigate. The svn copy (now a merge from git) is less hassle. Commons is open to all ASF committers so if anyone here wants more frequent DBCP2 and POOL2 releases I am sure the Commons community would welcome them with open arms. >> The rationale was probably: you can fix bugs without having to wait for a >> DBCP release. I'm not certain this actually happened though. It has. >> 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 ? Performance wise DBCP1, DBCP2 and Tomcat-JDBC are all pretty much equal until you start to hammer the connection pool with concurrent borrows and returns. At that point DBCP1 performance falls off a cliff. DBCP2 and Tomcat-JDBC are so close you probably won't notice but Tomcat-JDBC does have a slight edge. Functionality wise, DBCP2 handles more edge cases by default than Tomcat-JDBC. Most (I'm not sure if all) can be handled by Tomcat-JDBC with additional configuration (usually extra interceptors). Tomcat-JDBC has better JMX support, particularly performance related metrics. > 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. I'm aware of a couple of clients at $work that had performance issues with DBCP1 that Tomcat-JDBC solved. I'm not aware of anyone switching from DBCP2 to Tomcat-JDBC for performance reasons. I do occasionally see folks switching in both directions to either avoid an edge case bug or to get a particular feature. > 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). We tried that before. Getting the votes to do a release was hard work. A number of releases failed. That is why we moved to releasing it as part of Tomcat. > Perhaps the git-migration would be an opportunity to do that. Or folks can just grab it from Maven Central which is what most users would do. FTR it has a dependency on JULI. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
