Please feel free to submit patches to address these concerns. -----Original Message----- From: Jeffrey Varszegi [mailto:[EMAIL PROTECTED]] Sent: Sunday, December 01, 2002 9:25 PM To: Jakarta Commons Developers List Subject: [pool] Re: GenericObjectPool should allow for manual population of the pool
You're right-- I've had the same thought for a little while now. 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... (Some of the) other weaknesses I think should be addressed in the pool package: 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 There are a few other things I've noticed as well. I'm not slamming anyone or any code, but inviting comment. I think that with some touching up, the pool package can be really good. Jeff --- [EMAIL PROTECTED] wrote: > 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 > > Summary: GenericObjectPool should allow > for manual population of > the pool > Product: Commons > Version: 1.0.1 Final > Platform: Other > OS/Version: Other > Status: NEW > Severity: Normal > Priority: Other > Component: Pool > AssignedTo: [EMAIL PROTECTED] > ReportedBy: [EMAIL PROTECTED] > > > I need an ObjectPool which blocks when exhausted and > is populated manually by > the client. Wouldn't it be nice if GenericObjectPool > provided this? I don't > see how adding this capability would detract from > any existing functionality. > All we need is a new method, addNewObject(), whose > implementation is very > similair to, but NOT the same as, returnObject(). > > Also, the factory should be truly optional. it makes > the class more flexible, > without any sacrifice in functionality. the current > implementation which > allows construction of a GenericObjectPool without a > factory, but throws > NullPointerException when used, is broken. There's > no way that can be > considered robust code. > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
