I think that currently an application could call Connection.close() while retaining a reference to a Statement object and continue using it. The specification does not require Connection.close() to call Statement.close on any associated Statement(s). Is there a use case for closing a Connection while expecting a Statement to remain active?
The general principal when developing a jdbc compliant pool is that the application should experience similar behavior whether a Connection came from a pool or not. I would expect that if a Connection was actually physically closed that operations on its Statement(s) or ResultSets to fail. Would anyone counter that expectation? This situation would appear to be the opposite of the abandoned connection problem, where helping a badly coded application would be straightforward and receiving an sql exception after calling ResultSet.next() on a closed Connection would be preferrable to having multiple threads continuing to use ResultSets while the Connection keeps getting returned to the pool. A related question: I have never found a reason to keep multiple Statements on a single Connection open. The spec states that only a single ResultSet can be open on a Statement at a time and that multiple Statements should be used if multiple open ResultSets are required. Should this be interpreted to mean multiple open Statements per Connection are allowed? john mcnally --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
