>The notion expressed by someone else of creating new wrappers for each request delegating to truly pooled >connections, with the wrappers discarded when the connection is returned to the pool would prevent refrences to >wrappers being used to access the real pooled resources. >On the other hand this safety might negate too much of the performance boost pooling provides.
Due to the discussion, i have disabled the "abandoned connection" feature and try to live without it, in fact, i am not happy with this, but maybe sometimes one might create an alternative pool with this features ... In debug-mode there sould be a list of "connections handed out", but ... i hear it already ... this should be done by the user. However, passing an wrapped instance of the pooled connection, like my submitted patch do e.g. new ConnectionFacade(pool.getConnection()) could never ever cost so much performance like creating a new connection, nor could it slow down the application. Java should handle lightweight objects like this in lightspeed. And how often do an application request an connection compared to the number db-operations done via this connection? Using "ThreadLocal" or the proxy method does not help anything, and do not solve the problem. The application works on the proxy, but the pool get back the real connection, and there is no chance to notify the proxy in any way. We (the developer) do have definitly no chance to handle the "abandoned connection" situation without add some code to DBCP, maybe i oversee what, but then, please provide a working example where an application access the pool through the dbcp-datasource defined in an tomcat configuration. I am ready to learn something :-) Mario --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
