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

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to