Mailing-List: contact ojb-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "OJB Developers List" <ojb-dev@db.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <4213BC56.8010802@surfeu.fi>
Date: Wed, 16 Feb 2005 23:34:14 +0200
From: Ilkka Priha <impriha@surfeu.fi>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.7.5) Gecko/20041217
MIME-Version: 1.0
To: OJB Developers List <ojb-dev@db.apache.org>
Subject: Re: Closed connections in pool
References: <42138167.9060803@surfeu.fi> <42138A53.4050006@apache.org>
In-Reply-To: <42138A53.4050006@apache.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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