commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bowler Simon" <Simon.Bow...@thomson.net>
Subject RE: [Pool] New class/modification
Date Thu, 19 Aug 2004 02:20:00 GMT
Dirk (and group),

Attached are the patches for the files modified. The behaviour is now
similar to GenericObjectPool (except that the pool size is based on
key). Currently it does not take into account the maximum size of the
total pool (maxTotal). It looks only at the pool size per key. I have
also made the calculateDefecit method public, so that it could be
overridden in order to use a different defecit calculation method.

I have documented my modifications and added 4 test cases.

These patches are for the files contained in CVS, not the 1.2 release.

Cheers,

Simon

-----Original Message-----
From: Dirk Verbeeck [mailto:dirk.verbeeck@pandora.be]
Sent: Wednesday, 18 August 2004 7:17 PM
To: Jakarta Commons Developers List
Subject: Re: [Pool] New class/modification


Yes, please change it to be the same as GenericObjectPool.

Thanks
Dirk


Bowler Simon wrote:
> 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:dirk.verbeeck@pandora.be]
> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
> 
> 



Mime
View raw message