Thanks for helping me figuring this out one, Dan!
> To really follow the JDBC spec I think what is needed is:
> 3) If Connection.close() leads to a statement being completed (JDBC
> 4 section 10.1) then a commit should be triggered.
I think the standard requires statements to be closed when connection
is closed(9.4.4), but "closed" may not (always) imply "completed"? If
they are not the same, then it would appear that, yes, a transaction
can still be active an an exception should be thrown.
Can you help me understand when that would be the case?
I can't understand how it is possible for selects:
Section 15.2.5 Closing a result set object says:
A ResultSet object is explicitly closed when
- (bullet 2) The Statement or Connection object that produced the ResultSet is
This leads me to the following implication chain:
closing connection => closing result set
=> statement is completed
and then autocommit.
For callable statements it is more murky..
For a callable statement, the is no guidance as to whether a closing
of the connection also implicitly handles the outstanding inout and/or
result count, but I think it is a reasonable, symmetric expectation.
So I still think 1a) is correct, at least for SELECTs.
> JDBC 4 seems to indicate that both those ResultSets are open and can
> be used within a single auto-committed transaction. The transaction
> will be committed when rs1 or rs2 closes, whichever happens first.
> Note that Derby implements JDBC 3 in that it performs a commit (in
> auto-commit) on any execution within the connection. I wonder if
> JDBC 4 intended to make this change in behaviour.
Yes, I remember this one. I think it was intentional, but I have
pinged Lance again! If it is intentional, we could file another issue