tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <>
Subject Re: Tomcat connection pool contribution
Date Tue, 21 Oct 2008 16:08:27 GMT
Tim Funk wrote:
> Oddly enough - I started reading the code today. There are some minor 
> tweaks without digging too deep into the code:
> This should be CLOSE_VAL.equals(method.getName())
> if (CLOSE_VAL==method.getName()) { .
aren't method names in the constant pool?

> PoolProperties
> protected String name = "Filip Connection Pool["+(poolCounter++)+"]";
you don't like it :) LOL, things are still to be fixed.
> What I haven't read through is how concurrent threads return/borrow at 
> the same time.
that is the core of the pool, and could still be tuned, but in 
comparison to other choices, its a non issue for quite a while
> Given that dbcp feels like it has one foot in the grave, has many 
> dependencies, it would reduce the bloat by adding this as a module and 
> removing dbcp. If this would go to 6.0.x - it can't be default since 
> it would break many installations.
it wouldn't default in 6.0.x, that's not been on the table. It also 
wouldn't break a single installation, it uses the exact same settings, 
(unless of course someone uses casting)

> -Tim
> Filip Hanik - Dev Lists wrote:
>> gentlemen,
>> having run into issues with performance around commons-dbcp as number 
>> of logical cpus increase, no such method exceptions using newer JDKs, 
>> I've made a small code contribution
>> description and documentation is in the bug, and attached to the bug 
>> as an XML document.
>> I would propose
>> 1. add as default connection pool when type=javax.sql.DataSource in 
>> trunk
>> 2. ship as an alternate pool with 6.0.x but not enabled by default
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message