commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Kranz <patrick.kr...@netpioneer.de>
Subject Re: [dbcp] Re: Timeout for Idle Connections
Date Tue, 23 Feb 2010 14:57:50 GMT
Thanks, I created the feature request: 
https://issues.apache.org/jira/browse/DBCP-325

Patrick


Am 23.02.2010 12:11, schrieb Phil Steitz:
> Patrick Kranz wrote:
>    
>> Hello Phil,
>>
>> thanks for you response. If I understand these properties correctly,
>> they set the time a connection will reside idle in the idle pool. What I
>> mean is that a connection is created because all connections that were
>> in the pool are in use. This new connection would be closed immediately
>> if in the moment close() is called on this new connection, the pool
>> already has maxIdle connections. What I am looking for is a timeout that
>> says "I know this is one more idle connection than I configured but keep
>> it around for just a few more seconds in case we have a second peak so
>> we don´t need to construct the connection again".
>>
>>      
> Got it.  That feature is not currently available and as far as I
> know has never been suggested.  You could open a JIRA requesting the
> feature here:
> http://commons.apache.org/dbcp/issue-tracking.html
>
> Phil
>    
>> Cheers,
>> Patrick
>>
>>
>>
>> Am 23.02.2010 03:18, schrieb Phil Steitz:
>>      
>>> Patrick Kranz wrote:
>>>
>>>        
>>>> Hello list,
>>>>
>>>> I've been playing around with the DBCP for quite some time now, because
>>>> I want to get rid of Oracles Connection Pool. The only problem I still
>>>> wasn't able to solve is the following:
>>>>
>>>> In my Oracle Pool a connection gets closed within the pool after some
>>>> configurable amount of time. That means, if I have configured a maximum
>>>> idle of 4 and a maximum active of 10, the six connections that are
>>>> between these two limits are closed after for example 30 seconds. That
>>>> way these connections stay open as long as my period of high load lasts,
>>>> even if there are a few seconds without the need for more than 4
>>>> connections.
>>>>
>>>> The DBCP seems to work differently meaning that with the same
>>>> configuration every connection that is outside the maxIdle limit is
>>>> closed the moment the connection is returned to the pool.
>>>>
>>>> Maybe my assumption is wrong but I think depending on the way the
>>>> application is used, the way DBCP handles connections might result in a
>>>> higher rate of constructing new connections.
>>>>
>>>> So, is there any way to achieve the "Oracle way" that I did not stumble
>>>> into or was this simply never considered?
>>>>
>>>>
>>>>          
>>> See the minEvictableIdleTimeMillis property of BasicDataSource
>>> and/or softMinEvictableIdleTimeMillis of GenericObjectPool if you
>>> are managing the pool directly.  To use either of these properties,
>>> you need to enable the idle object evictor by setting the
>>> timeBetweenEvictionRunsMillis property to a positive value.
>>>
>>> Phil
>>>
>>>
>>>        
>>>> Cheers,
>>>> Patrick
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: user-help@commons.apache.org
>>>>
>>>>
>>>>          
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: user-help@commons.apache.org
>>>
>>>
>>>        
>>
>>      
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>    


-- 
Patrick Kranz
Software-Entwickler

Netpioneer GmbH, Schumannstr. 9, 10117 Berlin
Geschäftsführer: Axel Jahn
HRB: 107521 Handelsregister Mannheim

Tel: 030 / 5 20 02 36 33
Fax: 030 / 5 20 02 36 30
E-Mail: patrick.kranz@netpioneer.de
www: http://www.netpioneer.de


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


Mime
View raw message