Daniel John Debrunner wrote:
Dag H. Wanvik wrote:


"Daniel" == Daniel John Debrunner <djd@debrunners.com> wrote:

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

This has never been the intent in JDBC since its inception,  From the 1.0.2 spec:

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.


 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)

Interesting on the 4.0 stuff, that's a change in behaviour from 3.0, I
wonder if any applications would rely on the 3.0 executing on another
statement behaviour. Of course we shouldn't change until 4.0 is
official, and then do we support two behaviours, one for 3.0 and one for
4.0? Probably a future discussion on the dev list.

The 4.0 changes will allow multiple open statements per Connection in
auto commit mode, as opposed to a single one in 3.0. That's an
interesting change, I wonder if this will break any assumption in Derby
in autocommit mode. I'm also not sure that the changes help in the area
driving this discussion, allowing multiple threads to share a single
connection. It seems that the same basic problem exist, without
application synchronization, activity on one thread will modify the
state of the objects being used by the other thread.