db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Waibel <arm...@apache.org>
Subject Re: Closed connections in pool
Date Thu, 17 Feb 2005 13:51:23 GMT
checked in the patch, I don't apply the changes in 
getConnectionFromPool(...) but I improved the validateObject(...) method 
in ConnectionFactoryPooledImpl, please have a look at it.

regards,
Armin

Ilkka Priha wrote:
> Hi Armin,
> 
> As far as I understand it, testOnBorrow and testOnReturn will try to 
> execute the validation query for the Connection to check the server 
> side, but in this case the client side has closed the Connection. Of 
> cource the validation query would find this one also, but such a query 
> is quite costly compared to checking one boolean member of the 
> Connection instance and could be useless in 99 % of Connection retrievals.
> 
> We do apply testOnIdle, which logs an error that a closed Connection 
> can't be validated every time it finds a closed one from the pool, so it 
> seems that Connection validation is not meant to pick up Connections 
> closed in client side. I haven't checked the code how testOnBorrow and 
> testOnReturn do it, but according to documention they are part of the 
> same "testOn" series.
> 
> Anyways, I agree that it's reasonable to perform a simple check 
> independently on the connection settings to avoid problems and thanks 
> for applying the patch, so we can remove our extension and rely on 
> default implementations :-)
> 
> -- Ilkka
> 
> 
> Armin Waibel wrote:
> 
>> Hi Ilkka,
>>
>> Ilkka Priha wrote:
>>
>>> Hello
>>>
>>> We noticed that under heavy load (lack of memory) OJB returns closed 
>>> Connections into the pool. This happens when the finalizer activates 
>>> the finalize method of PersistenceBroker instances. At least MySQL 
>>> Connections are already closed at this point (their finalize called 
>>> as well?). Closed Connections cause a lot of trouble later on when 
>>> borrowed back to use from the pool.
>>>
>>
>> isn't it possible to avoid these problems when you enable property 
>> 'testOnReturn' in connection-pool setting?
>>
>> <connection-pool
>>             maxActive="30"
>>             validationQuery=""
>>             testOnBorrow="true"
>>             testOnReturn="true"
>>             whenExhaustedAction="0"
>>             maxWait="10000"
>>         />
>>
>> If 'testOnReturn' is true the ObjectPool validate the connection 
>> before it was returned to pool.
>> http://jakarta.apache.org/commons/pool/apidocs/index.html
>>
>>
>>> System Thread [Finalizer] (Suspended (breakpoint at line 61 in
>>>     ConnectionFactoryPooledImpl))
>>> ConnectionFactoryPooledImpl.returnConnectionToPool(JdbcConnectionDescriptor,

>>>
>>>     Connection) line: 61
>>> ConnectionFactoryPooledImpl(ConnectionFactoryAbstractImpl).releaseConnection(

>>>
>>>     JdbcConnectionDescriptor, Connection) line: 90
>>> ConnectionManagerImpl.releaseConnection() line: 314
>>> PersistenceBrokerImpl.close() line: 336
>>> PersistenceBrokerImpl.finalize() line: 1946
>>> Finalizer.invokeFinalizeMethod(Object) line: not available [native 
>>> method]
>>> Finalizer.runFinalizer() line: 83
>>> Finalizer.access$100(Finalizer) line: 14
>>> Finalizer$FinalizerThread.run() line: 160
>>>
>>> We added a simple check to an extended version of the 
>>> ConnectionFactoryPooledImpl, which fixes the problem and could be 
>>> applied to the original version, too.
>>>
>>
>> thanks, I will add the con.close check to all pooling 
>> ConnectionFactory implementations. This will help to avoid problems 
>> with closed connection independent from connection-pool settings 
>> (think con.close() isn't costly to perform, so it doesn't matter if it 
>> was performed twice on return of the connection - testOnReturn enabled).
>>
>> regards,
>> Armin
>>
>>> -- Ilkka
>>>
>>>     public void returnConnectionToPool(JdbcConnectionDescriptor jcd,
>>>         Connection con) throws LookupException
>>>     {
>>>         try
>>>         {
>>>             if (!con.isClosed())
>>>             {
>>>                 super.returnConnectionToPool(jcd, con);
>>>             }
>>>         }
>>>         catch (LookupException x)
>>>         {
>>>             throw x;
>>>         }
>>>         catch (Exception x)
>>>         {
>>>             throw new LookupException(x);
>>>         }
>>>     }
>>>
>>>     public Connection getConnectionFromPool(JdbcConnectionDescriptor 
>>> jcd)
>>>         throws LookupException
>>>     {
>>>         try
>>>         {
>>>             Connection con;
>>>             do
>>>             {
>>>                 con = super.getConnectionFromPool(jcd);
>>>             } while (con.isClosed());
>>>
>>>             return con;
>>>         }
>>>         catch (LookupException x)
>>>         {
>>>             throw x;
>>>         }
>>>         catch (Exception x)
>>>         {
>>>             throw new LookupException(x);
>>>         }
>>>     }
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>> .
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
> 
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Mime
View raw message