Ilkka Priha <impriha <at> surfeu.fi> writes: > 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.
I don't think that is entirely correct. Extract from Commons Pool JavaDoc: "When testOnReturn is set, the pool will attempt to validate each object before it is returned to the pool in the returnObject(java.lang.Object) method. (Using the provided factory's poolableObjectFactory.validateObject(java.lang.Object) method.) Objects that fail to validate will be dropped from the pool." Please note that Commons Pool is a generic API and the definition of "valid" is left to the specific object factory. When used in OJB's ConnectionFactoryPooledImpl, the definition of valid is: 1) check !con.isClosed (<== NB!) 2) if, and only if, #1 passed - issue validation query Thus what you are trying to achieve seems to already have been implemented before the patch by just setting testOnReturn. > 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. As stated above, I think this assumption is wrong. See http://jakarta.apache.org/commons/pool/apidocs/index.html and the OJB ConPoolFactory (inner class of ConnectionFactoryPooledImpl), method validateObject. > I haven't checked the code how testOnBorrow and testOnReturn do it, but > according to documention they are part of the same "testOn" series. The configuration settings are just "lifecycle" modifiers setting when validation should occur. The definition of validation is provided by OJB by implementing validateObject and checking criteria #1 and #2 above. I am reviewing the connection validation logic at the moment and the patch is actually creating problems in maintaining the OJB code, since there is API contract breakage by doing additional validation in releaseJdbcConnection. I agree that the definition of OJB Conenction validation is not really clear and it's a bit of a "djungle" at times tracing the logic in the connection factories in this particular aspect. I will try to provide better JavaDoc and see if I can clean things up a bit, but however I formulate the JavaDoc this additional validation check is in the way (as is a similar, but older, artifact in lookupConnection). I would really appreciate the help if your could test with an OJB version previous to your patch applied and just set testOnReturn to true, since you seem to have a reproducable environment. If you can't get it to work we need to "punch a hole" in my arguments above and readjust API contracts accordingly. Regards, Martin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
