Well it's not exactly the same as minIdle. Where minIdle only looks at the pooled idle instances. This implementation looks at the total pool for a key (active and idle).
For consistancies sake, should we change it to be the same as GenericObjectPool and keep a minimum level of idle instances? I have integrated the changes into GenericKeyedObjectPool, following feedback to these questions, i will post a patch. Cheers, Simon -----Original Message----- From: Dirk Verbeeck [mailto:[EMAIL PROTECTED] Sent: Tuesday, 17 August 2004 9:43 PM To: Jakarta Commons Developers List Subject: Re: [Pool] New class/modification OK, so you basically implemented the GenericObjectPool.setMinIdle feature but for a KeyedObjectPool. Very usefull addition, I would even merge it into GenericKeyedObjectPool itself. Having the same behaviour in the two generic implementations is a good thing. You can post your code here or make a bugzilla enhancement request and attach it to the issue. If you post the whole new file make sure you include the Apache 2 license and not your company license. Otherwise you can merge your new feature into GenericKeyedObjectPool and post a patch. Cheers Dirk Bowler Simon wrote: > Hi > > The purpose of the new class is to maintain a minimum number idle instances in a > pool, but grow as required up to a maximum number of active instances. The reason > for maintaining a minimum level of idle instances in a pool, is for efficiency. A > call to borrowObject() when there are no pooled instances available, must create an > instance of the object required. This causes delays when the object it is > instanciating needs to reserve resources or connect to remote systems (for example, > an SMTPConnection). > > The new class proposed, features the following: > > Same features as provided by GenericKeyedObjectPool (idle eviction, validation of > pooled objects on borrow/on return/when idle). > > Maintain a minimum number of pooled objects (per key). This number is configurable. > > A seperate thread will be used to periodically create any required objects to > maintain the minimum level. This time period is configurable. > > The pool must be aware of a key before it can start maintaining a minimum number of > pooled objects for that key. This can be performed by performing a > borrowObject(key). However, this results in a potential delay whilst the pooled > object is being created. An extra method preparePool(key) is used to give the pool > knowledge of the key, so that it can start maintaining a minimum number of pooled > objects for that key. This should result in a much quicker call to > borrowObject(key), as pooled instances will already be created and waiting in the > pool. > > The above features are essentially one patch. It was originally intended to extend > GenericKeyedObjectPool, and add the new features. However, the fields in > GenericKeyedObjectPool are private. > > > Dirk - In the case of our system we were pooling custom connections to remote > servers. These were not SQLConnections, but SQLConnections would also work with this > modification. > > Cheers, > > Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
