The MinIdle property is used to maintain a minimum number of idle
object in the pool ready to be used. So when the evictor thread runs
(every x milliseconds) it will test the existing idle objects and
add/remove when needed.
There is no initialSize property on GenericObjectPool.
But you can use the addObject method to populate the pool.
for (int i = 0 ; i < initialSize ; i++) {
pool.addObject();
}
The BasicDataSource implementation will have a initialSize property in
version 1.2 (currently in nightly build):
http://cvs.apache.org/viewcvs.cgi/jakarta-commons/dbcp/src/java/org/apache/commons/dbcp/BasicDataSource.java?r1=1.32&r2=1.33&diff_format=h
Cheers
Dirk
Vikram Goyal wrote:
> * Resending email sent to commons-dev *
>
> Hello,
>
> My query regarding the initial size of a pool seems so basic that I am
> sure that I am wasting your time. However, I have scoured the source
> code for both Pool and DBCP for the better part of a day and I am having
> trouble understanding how the initial size of a pool is maintained. I
> apologize in advance if the answer should be right in front of my eyes
> and I can't see it.
>
> At the moment, as I understand it, the only way to set the initial size
> of a pool is by the following code:
>
> pool.setMinIdle(5); // some random number
>
> pool.setTimeBetweenEvictionRunsMillis(200L); // basically set to a
> non-negative value
>
> As per the documentation and the code, the pool will only be initialized
> with the min idle value of 5 as specified above IF an Evictor thread is
> started. This can only happen by overriding the default value of -1 for
> "time between eviction runs millis" property of the pool.
>
>
> Is this assumption correct? Technically, this means that, with the
> default settings in place, no objects are present in the initial pool,
> as minIdle is set to 0 and the eviction thread is not started because it
> is only started for non-negative values of the above property. With
> these default settings, it also means that objects are added to the
> pool, only when they are requested the first time. This solves the
> purpose of reusability, provided the borrowed objects are returned, it
> gives slower response time for initial objects.
>
> This seems to me an odd way of initializing the pool. Why would you want
> the Evictor thread to initialize the pool as a side effect of its main
> work of evicting idle objects? Shouldn't the pool initialize itself
> based on an initial pool size property?
>
> Regards,
> Vikram
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
|