db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: I need some advice to choose database for an upcomming job
Date Tue, 08 Nov 2005 07:58:40 GMT
Dag H. Wanvik wrote:

> Hi,
>>>>>>"Daniel" == Daniel John Debrunner <djd@debrunners.com> 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)

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.


View raw message