Hi, I am still working on the ConnectionPool mechanism of Turbine trying to make a turbine application fully recover after a db restart. Although the last patch I proposed solves the problem of hanging connections there is still one problem: code that is already written that does not close the DBConnection after a fatal error will still not be able to work properly after a db restart. And unfortunately, all the BasePeer code of Turbine does not take that into account !!! (to be exact, on Sunday, after a db restart my turbine application did not allow anyone to login since the connection objects that existed in the pool always returned errors...) The best way to approach this problem is to make modifications to the ConnectionPool mechanism that will allow existing code to work as is without the need to close a connection in the case of error (since I suppose that applications that already use Turbine will not be able to recover either) So the magic should happen in the releaseConnection method of the ConnectionPool class. After some investigation, I concluded to the following: The only way for the ConnectionPool to close a connection if a fatal error occurs but the application programmer did not close the connection, is somehow to be notified of all Exceptions that occur and decide somehow what are the fatal ones. Since this is not doable, the only alternative approach is to use the JDBC2.0 standard extensions and use the PooledConnection interface instead of the connection class. The PooledConnection interface provides a notification mechanism through the standard event model that allows listeners to be notified of fatal errors (ConnectionEvent event). In order for this to work, the JDBC driver in use should support the JDBC2.0 spec. I believe that most of the drivers out there do support this, so I made a few modifications to the code so as to use real PooledConnection objects when they are available. To be exact, the way the DBConnection is currently used is not efficient and is actually a little frustrating. What the DBConnection attempted to do was to be used as a wrapper around normal Connection objects. Since the last modifications though and the addition of the PooledConnection interface in its implementation list, things got a little more complicated. Since a PooledConnection object should be returned by the JDBC driver , the only reason of the DBConnection object implementing the PooledConnection interface is just to provide a wrapper for 'old' Connection objects in order to have a uniform interface to the ConnectionPool class. But this is not the case since the implementation of the PooledConnection interface of DBConnection is not correct (e.g. the close method should not close the actual jdbc connection but just release it... according to the specs). On the other hand, not changing the DBConnection methods is also important so as not to break existent code. With these in mind, I propose the following changes. The idea is that the DBConnection is still used as a wrapper for Connection AND PooledConnection objects. Since this 'wrapping' is different for each case, the code has been modified to work each time with the semantics that each 'wrapped' class needs. Code specific details to the next post (this is too long)... ------------------------------------------------------------ To subscribe: [EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/> Problems?: [EMAIL PROTECTED]
