Tim Funk wrote:
Oddly enough - I started reading the code today. There are some minor
tweaks without digging too deep into the code:
ProxyConnection.java
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)
Filip
-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
https://issues.apache.org/bugzilla/show_bug.cgi?id=46038
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
