Hi, >>>>> "Daniel" == Daniel John Debrunner <[EMAIL PROTECTED]> wrote: Daniel>
Daniel> I think there was a long discussion on this about six months ago, lead Daniel> by Phil Wilder. He was trying to clarify autocommit mode and held cursor Daniel> behaviour in the JDBC spec. It's a little unclear, as for example, Daniel> section 10.1 was not updated for held cursors. That was a case where the Daniel> wiki would have been useful, to present a summary of the current discussion. Daniel> Daniel> And as you say, I think that discussion was driven by differences in the Daniel> client and embedded drivers in this area. I talked to Lance about the spec being vague on this issue, and the new draft for JDBC 4.0 (http://www.jcp.org/aboutJava/communityprocess/edr/jsr221/index2.html) has a new and clearer wording: > 16.2.5 Closing a ResultSet Object > > A ResultSet object is explicitly closed when > - The close method on the ResultSet is executed, thereby releasing any > external resources > - The Statement or Connection object that produced the ResultSet is > explictly closed > > A ResultSet object is implicitly closed when > - The associated Statement object is re-executed > - The ResultSet is created with a Holdability of > CLOSE_CURSORS_AT_COMMIT and an implicit or explicit commit occurs > > Note: Some JDBC driver implementations may also implicitly close the > ResultSet when the ResultSet type is TYPE_FORWARD_ONLY and the next > method of ResultSet returns false. Note that executing a statement on *another* statement object in the same connection no longer closes a result set, and hence should no longer trigger an auto-commit¹. I find the new wording more logical, and I think we should try to move the implementation of Derby towards this behavior. ¹Auto-commit is triggered for select statements when the result set is closed, making that statement complete (Section 9.1) Dag
