DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14983>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14983 GenericObjectPool should allow for manual population of the pool ------- Additional Comments From [EMAIL PROTECTED] 2002-12-02 18:33 ------- 1. Unintuitive naming makes the code hard to reuse for people that didn't write it 2. There's no way to set a minimum number of 'idle' objects 3. The WHEN_EXHAUSTED_GROW strategy: there's nothing provided by this that isn't provided by setting an infinite maximum 'active' size 4. Dependencies on things like CursorableLinkedList that aren't really necessary make the pools tougher for end users to just drop into their code 5. Failure to synchronize on a hidden monitor means that an outside process can indefinitely lock implementations like GenericObjectPool 6. The 'factory' (which isn't really a factory, but a full lifecycle manager) is necessarily involved in all steps of GenericObjectPool, but there isn't full support for its use. For instance, the fact that a 'factory' has an activateObject() method doesn't mean it should be called every time an object is gotten from the pool; this strategy should be settable at the pool level. There are numerous good reasons for this, not least of them being that in an environment where high availability is most important, it might be desirable NEVER to passivate a pooled object, even if it's possible. 7. Class GenericObjectPool.Config provides no extra functionality 8. Callers of methods that acquire objects from the pool should be able to provide their own timeouts 9. There should also be a method to check something out of the pool permanently (so that the removed object doesn't count against the pool's maximum), in case some process would like to hold onto a connection or something similar for a long time, and would like to assume all responsibility for the object. This could be an optional operation, or a strategy could be settable... 10. The validate() method is appropriate for checking the validity of an object. Another method, refresh() or renew(), should be provided for cases where leases on resources must be renewed at set intervals, etc. This should not depend on other functionality-- lifecycle management shouldn't be an all-or- nothing proposition. Sorry I didn't put these here earlier-- I inappropriately sent them to the list. I don't mind developing patches, but I think there should be discussion first. Jeff -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>