Good point on access to configuration variables. I am thinking of the local
variables in the class as two types: Configuration, and runtime. The
configuration variables do not change in our application, therefore access
was not always synchronized. This will be a problem for applications that
wish to change the configuration of the pool on the fly. The runtime
variables (like numActive) are changed when threads use the pool, and they
are all synchronized.
Since we do not plan on dynamic configuration (yet), we think of the
configuration variables as constants. This of course is not acceptable for
general purpose use, because the class was written to support dynamic
configuration.
To make this implementation usable in the general case, access to all
variables probably needs to be synchronized.
I think of a few of ways to do that:
1. Use the getters, which are mostly synchronized
2. Localize variables on the stack in all functions that are not fully
synchronized, and initialize in a synchronized block. This is more atomic,
as values that change while the code is running will not affect it. Example:
final int whenExhaustedAction;
final int maxWait;
final List pool;
synchronized(this){
whenExhaustedAction = _whenExhaustedAction;
maxWait = _maxWait;
pool = _pool;
}
3. Use an object that holds all static configuration data, and get a
reference to it in the beginning of the function. This is the most atomic. A
synchronized getter would be nice:
synchronized Config getConfig() { return _config; }
As for changing the structure of the functions, I agree there are benefits.
However, we ended up with massive copy-pastes because there was no other way
to extend the code. We would like to keep things as close as possible to the
original code, it is already non trivial to follow the changes. Changing the
function signatures will make it harder to deal with when we upgrade.
Thanks for feedback. To actually submit a patch this needs more work as you
noticed, maybe in a few weeks. To be honest, I didn't see much response to
your patch, which I have to say is very surprising. This is a critical piece
of code and it is widely used (shipped as standard with Tomcat). There is
also the release candidate that contains performance improvements that is on
hold for a while. The download page has the latest version as June 2004!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
