db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Re: JDBC auto-commit semantics challenge
Date Sun, 26 Jun 2005 00:07:26 GMT
Lance J. Andersen wrote:

> i have not had the bandwidth to follow this thread due to J1 and a few
> other fire drills.  We have made changes to the spec and javadocs in
> JDBC 4 to clarify things in these areas.  Please take a look and see
> if there is still something you feel needs clarified.
>
Yes. Could you clarify a few things regarding section 9.1. Transaction
Boundaries and Auto-commit
Most of the confusion  stems from a lot of different/additional
information in the javadoc for setAutoCommit.

1)   The spec says that the result set is closed when invocation of its
next method returns
false.  Does this mean an additional call to next should throw an
exception that the result set is closed or should it just continue to
return false? 

2) Is the  definition of when  non-holdable cursor result sets  are
closed  really needed or could b and c  be combined into
    "a commit occurs on the connection", because I think it is the
commit that b and c trigger that are the cause of the result set closing
not the execution of the statement itself.
    b. the associated Statement object is re-executed
    c. another Statement object is executed on the same connection

3)  For callable statements the spec says "the statement is complete
when all of the associated result sets have been closed"
   but the setAutoCommit javadoc also seems to require that other
results such as  results which are update counts and output parameters
be retrieved.  How do these play into statement completion?

4) Section 9.1 does not mention that setAutoCommit itself might also
trigger a commit itself.  That might be good to put that in this
section.  In Derby setAutoCommit only commits if the autocommit status
changes.  

5) How should DatabaseMetaData calls affect commit? Since the statement
itself is not  exposed, should  execution of a metadata call send a
commit or have special handling to avoid this?

Here is a link to Philip's analysis for reference.  He has been doing it
as part of our work for DERBY-213 which we found required a thorough
understanding of the interaction of autocommit and result sets, a state
of enlightenment I still have not reached.

http://mail-archives.apache.org/mod_mbox/db-derby-dev/200506.mbox/%3c42BC0C49.3030403@acadiau.ca%3e

Thanks for the clarification

Kathey






Mime
View raw message