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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
