We need to make a decision on whether or not to change the contract for PoolableConnection (or DelegatingConnection or PoolGuardWrapper) isClosed. There are two changes suggested in DBCP-398:
1) Currently, isClosed returns true if the connection handle has been closed by the client *or* the underlying connection's isClosed returns true. So if a connection has been closed server-side and the driver reports this via isClosed on the physical connection, DBCP clients get true returned even if they have not called close on the handle. This behavior goes back to DBCP 1.0. 2) When a PoolableConnection is closed by the client and it has already been closed server-side (i.e. the driver's isClosed returns true on the physical connection) an SQLException is thrown. This behavior is newly distinguished in DBCP 1.3/1.4. Prior to the latest releases, if isClosed (with semantics above) returned true, SQLException was always thrown. In 1.3/1.4, we made close idempotent, so multiple client-side calls to close no longer generate an SQLException. We decided, however, to still throw when close is invoked on a connection handle whose underlying physical connection's isClosed returns true. As of now, 1.X and 2.0 code behave the same way. We have several alternatives to choose from here: a) Do nothing - i.e., keep the contract as it is b) "Fix" in 2.0 c) Fix in 1.X If we do change the contract in 1.X, I am not sure it is OK to do that in 1.3.1/1.4.1 - i.e. would have to move to 1.5, 1.7 or something (recall that 1.3 is for JDK 1.4-1.5, 1.4 is JDK 1.6). "Fixing" 2) is straightforward. For 1), my inclination would be to just change DelegatingConnection#isClosed; but logically the least change approach would be changing PoolGuardConnectionWrapper (followed by PoolableConnection, DelegatingConnection). Whatever we decide, we should make sure to document it. Unfortunately, current behavior is not spelled out in the javadoc. It would be great to get some others' feedback on how best to proceed. Phil --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
