commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Waldhoff, Rodney" <rwald...@us.britannica.com>
Subject RE: [pool] Re: GenericObjectPool should allow for manual populati on of the pool
Date Mon, 02 Dec 2002 16:39:05 GMT
Please feel free to submit patches to address these concerns.

-----Original Message-----
From: Jeffrey Varszegi [mailto:jeff@generalize.net]
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

--- bugzilla@apache.org 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: commons-dev@jakarta.apache.org
>         ReportedBy: sschwell@yahoo.com
> 
> 
> 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:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:commons-dev-help@jakarta.apache.org>
> 


--
To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message