> I have been stricken with the beauty of approach > you have proposed, indeed its nice to emulate > a server timeout :-))
I can see how this would appeal, allowing DBCP to impose its own timeout, however IMO it would still not allow DBCP be able to reclaim the connection, Rather it would have instead to mimic the servers response to a timeout, which might only become apparent when the connection is used, and not have any affect if the routine holding the connection is accessing properties and methods of the connection which are handled offline. In this event it would therefore appear to be almost impossible to achieve any real advantage for the pool, in that it would still not be able to legitimately reclaim the connection or close it, unless that can be done without breaking existing ResultSet's, StoredProcedures and so on. For example connecting to MySQL using JDBC it is possible to attempt to use a connection which no longer exists, and only on the execution of an SQL query does the driver return an error. This is because the instance of Connection is not closed, it is simply no longer capable of contacting the RDBMS. Even when that error is issued it is *still* the responsibility of the user to call close(), JDBC doesn't reclaim the object and garbage collect it for you. Therefore I contend that it would be inconsistent for DBCP to behave otherwise, and it would also be of little use for preventing leaks as leaked connections will most likely never be used again, and so never be seen to timeout. > I'm afraid something nasty may happen if while > the user is executing a lengthy query another > thread close()-s the connection. This is one of my primary reasons for siding against intervention by the pool, it is not within the remit of a pool to dictate how the resources should be used. In use, IMO, any pool or cache should intervene between programme and resource in a manner which is completely transparent. It should never be the case that a pool or cache can cause the failure of the resource where the resource is being used legitimately according to its specification, JDBC makes no restriction on the length of time connections can be held for and therfore neither should any JDBC connection pool. If this causes problems for the user it is because they are either using the pool inapropriately or their code is broken. In neither situation has the case been well argued that the pool should attempt to correct this in preference to the developers of the software. d.
