commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Danny Angus" <>
Subject RE: Re[2]: DBCP status?
Date Mon, 30 Jun 2003 13:48:16 GMT
> 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.

View raw message