Phil,

many thanks for your reply on this - basically, i am now using the setMaxActive 
to set the active instances to one per key, which does what i want it to do, 
but i also have a cache wrapping the pool to keep a track of the active objects 
and then deliver the same object when requested by the same key - obviously the 
pool only keeps a handle on idle objects, so i have wrapped with my own class 
to keep a track of active objects by key - this appears to be working ok, so 
many thanks for your help here!

Cheerio,
Nic

Phil Steitz <[EMAIL PROTECTED]> wrote: 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?

Phil

On 7/20/07, Phil Steitz 
 wrote:
> On 7/19/07, Nicholas Hemley  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 possible?
>
> 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.
>
> Phil
>
> > 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]




       
---------------------------------
 Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for 
your freeaccount today.

Reply via email to