db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: DERBY-213 Autocommit issue
Date Fri, 10 Jun 2005 15:25:13 GMT
Philip Wilder wrote:

> Hello,
> As I am sure most of you are aware Kathy and I have been working on
> DERBY-213 (http://issues.apache.org/jira/browse/DERBY-213) for while
> now. We have recently put the finishing touches on a promising patch
> when I ran into a little snag.  Somehow while looking over the code I
> managed to overlook this comment until recently:
> /*
> * From Connection.setAutoCommit() javadoc:
> *    The commit occurs when the statement completes or the next execute
> occurs, whichever comes first.
> *    In the case of statements returning a ResultSet object, *the
> statement completes when the
> *    last row of the ResultSet object has been retrieved* or the
> ResultSet object has been closed.
> */
> This may or may not be a problem. The nature of our change to the client
> side code is to make sure the closeX() method is only called on errors
> or explicit close requests, a closed server side ResultSet or exceptions
> rather then the first time the .next() method returns false. However at
> the moment all of the autocommit logic is in the closeX() method, so by
> altering when the closeX() function is called we are altering the
> autocommit logic. This comment would seem to indicate that we must by
> necessity commit any changes to the ResultSet when the last row of the
> ResultSet is retrieved but I'm not sure what there is to commit. I
> believe all of the .getXXX() calls to the ResultSet are readOnly,
> .updateXXX() calls must be finalized with the UpdateRow() method before
> the .next() method is called or the updates will be discarded and insert
> functionality is not supported by the Client Driver.
> So are we doing any harm by releasing this patch or is this the fix we
> are looking for? The proposed changes do not seem to cause any problems
> in the derbyall suite but this may be a lapse in the test suite rather
> then good design decisions on our part.

A commit 'commits the transaction', which is a broader statement than
'commits the changes'. In most isolation levels read locks can be held
until the end of the transaction, and are released by the commit. Thus
even in a read-only transaction, commits are required.

Does that help?

View raw message