[DBCP] should Connection.close() render associated Statement objects unusable.

[John McNally <jm...@collab.net>]

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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [DBCP] should Connection.close() render associated Statement objects unusable.

[David Graham <gr...@yahoo.com>]

--- John McNally <jm...@collab.net> wrote:
> 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?

Closing a Connection should *always* close the resources obtained from
that Connection including Statements and ResultSets.  It would be highly
confusing to implement it any other way.  Imagine calling
Statement.getConnection() to generate another Statement and receiving an
SQLException because the Connection is closed.  That's completely
nonsensical.

> 
> 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?

Multiple open Statements per Connection are allowed.

David

> 
> john mcnally 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org