DO NOT REPLY [Bug 14983] - GenericObjectPool should allow for manual population of the pool

[bu...@apache.org]

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 jeff@generalize.net  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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>