One more note on this.  GenericKeyedObjectPool does allow you to limit
the number of *active* instances per key, using setMaxActive(key). If
you want to allow one or more to be active, but just to limit the
number cached in the pool (numIdle) to 1 per key, this is not possible
directly and you need to subclass.  What exactly are you trying to do?


On 7/20/07, Phil Steitz <[EMAIL PROTECTED]> wrote:
On 7/19/07, Nicholas Hemley <[EMAIL PROTECTED]> wrote:
> Hello,
> I am using the commons pool for a project and would like only one object 
instance to be stored per key using the GenericKeyedObjectPool - is this actually 

No, not directly.
> The javadoc for KeyedObjectPool states that:
> "KeyedObjectPool implementations may choose to store at most  one instance per key 
value, or may choose to maintain a pool of instances  for each key (essentially creating a 
Map of  pools)."
> However, having looked in the codebase, the GenericKeyedObjectPool implements 
a linkedlist of objects, with no option for setting one object per key only...

The problem is not actually with the backing store, but the maxTotal
property not configurable per key.  If this is what you want, or
anyone else thinks this would be useful, please open a Jira ticket
asking for this enhancement.
> Also, I am unable to subclass GenericKeyedObjectPool to alter the behaviour 
since the members are all private, so that is not an option.

One workaround would be to subclass and override borrowObject to check
numIdle(key) and numActive(key) before calling super.borrowObject().
If numIdle(key) is 1, borrow the instance. If it is 0 and
numActive(key) is 1, wait or fail, depending on config.  If both are
0, call addObject and then borrowObject.  This is awkward, but could
be made to work.

If what you really want is a KeyedObjectPool that has maxTotal
configurable per key, then open a JIRA (ideally with a patch) and we
can look at implementing that.


> Another option would be to add a custom implementation to my project, however 
certain member variables e.g. GenericObjectPool.EVICTION_TIMER are not visible, 
which procludes this approach. The only option would be to add a new class to the 
commons jar, which I am loathe to do since then it will not be compatible with 
future releases e.g. v2.
> Many thanks for any feedback.
> Cheerio,
> Nic Hemley
> ---------------------------------
>  Yahoo! Answers - Get better answers from someone who knows. Tryit now.

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to