Daniel John Debrunner wrote:
Dag H. Wanvik wrote:
"Daniel" == Daniel John Debrunner <firstname.lastname@example.org> 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
- The Statement or Connection object that produced the ResultSet is
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
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
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
¹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.