Daniel John Debrunner wrote:
Lance J. Andersen wrote:

  
Note that executing a statement on *another* statement object in the
same connection no longer closes a result set, 

        
This has never been the intent in JDBC since its inception,
    

Well, it sure had a funny way of showing it was not the intent :-)

JDBC 1

"New JDBC connections are initially in “auto-commit” mode. This means
that each statement is executed as a separate transaction at the
database. In order to execute several statements within a single
transaction, you must first disable auto-commit by calling
Connection.setAutoCommit(false)."
  
I assume you are refering to the JDBC 102 spec , i am aware of this verbage.

The above wording does not specify what happens to the Statement that was active.  Is it commited or rolled back?  I am sure your milage varies as it does if you do a Connection.close() and there is an active transaction (The SQL standard differs from the reality of vendors.  Some commit, some rollback some just give an Error and expect the user to address it as the standard suggests)


JDBC 3

"For Select statements, the statement is complete when the associated
result set is
closed. The result set is closed as soon as one of the following occurs:
[...]
- another Statement object is executed on the same connection"

Pretty explicit in both cases, only a single statement can be active in
auto-commit mode. JDBC 4.0 is proposing a change that multiple
statements, possibly including updates, can be active when in
auto-commit mode. I wonder if that was really the intent of EG for these
changes?
  
The JDBC 3 spec intermixed when a ResultSet was closed with auto-commit semantics and these both are seperate scenarios.  These should have been seperated.


The verbage in JDBC 3 WRT to  having another Statement executed on the same connection was not explict WRT auto commit as it was written and led to confusion.

Perhaps 1 more bullet could be added to clarify this *specific* scenario as to the state of the ResultSet, i will see.

  
From the 1.0.2 spec:
    

  
Multi-threading
We require that all operations on all the java.sql objects be
multi-thread safe and able to cope
correctly with having several threads simultaneously calling the same
object.
Some drivers may allow more concurrent execution than others. Developers
can assume fully
concurrent execution; if the driver requires some form of
synchronization, it will provide it.
The only difference visible to the developer will be that applications
will run with reduced concurrency.
For example, two Statements on the same Connection can be executed
concurrently and their
ResultSets can be processed concurrently (from the perspective of the
developer). Some drivers
will provide this full concurrency. Others may execute one statement and
wait until it completes
before sending the next.
    

Derby/Cloudscape has always been completely compliant with the above
multi-threading section. This section is also not in conflict with the
current defined JDBC 3 auto commit behaviour.

Dan.