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 <[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 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]