db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kim Haase <Camilla.Ha...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-2060) SET CURRENT ISOLATION in ref.man refers java.sql.Connection.setTransactionLevel instead of java.sql.Connection.setTransactionIsolation
Date Wed, 29 Nov 2006 16:31:52 GMT
Bernt M. Johnsen wrote:
>>>>>>>>>>>>> Daniel John Debrunner (JIRA) wrote (2006-11-28
>>     [ http://issues.apache.org/jira/browse/DERBY-2060?page=comments#action_12454083
>> Daniel John Debrunner commented on DERBY-2060:
>> ----------------------------------------------
>> Connection.setTransactionIsolation() does commit the transaction
>> with the embedded driver unless the isolation is being changed to
>> the current isolation, ie. no change.
> Yes, you're right (but the netowrk driver will *always* commit). The
> problem is that a user may accidentally change the behaviour of his
> program just by altering a setTransactionIsolation call, even if the
> change in isolation level per se should not cause a change.
> I think that we should not allow setTransactionIsolation on an active
> transaction, and make Derby conformant with SQL 2003, where you're not
> allowed to do SET TRANSACTION if there is an active transaction or if
> there are any open holdable cursor from the last transaction (See
> section 16.2)

Do you mean SET ISOLATION rather than SET TRANSACTION? (I don't have 
access to the SQL 2003 standard.)

It seems that we have two issues here.

1) The desired change in SET ISOLATION behavior should be in a separate 
bug -- maybe DERBY-2064, which is not a documentation bug and where it 
is not clear right now what the needed change is, or maybe a new bug 
with the broader change.

2) Should we document the current behavior in the meantime, while 
waiting for the fixes? If so, what exactly is the current behavior? This 
is my understanding -- please correct as necessary:

If there is an active transaction, the network client driver always 
commits the active transaction if either SET ISOLATION or 
Connection.setTransactionIsolation is called. It does this even if the 
statement or method call does not actually change the isolation level 
(that is, if it sets the isolation level to its current value). The 
embedded driver also always commits the active transaction if SET 
ISOLATION is called. However, if Connection.setTransactionIsolation is 
called, the embedded driver commits the active transaction only if the 
call to Connection.setTransactionIsolation actually changes the 
isolation level.


> (The JDBC spec and Javadoc (both 1.4 and 1.6) says it's implementation
> defined, while the tutorial, 3rd ed., says that the call *will*
> commit. [sigh!])
>>> SET CURRENT ISOLATION in ref.man refers java.sql.Connection.setTransactionLevel
instead of java.sql.Connection.setTransactionIsolation
>>> --------------------------------------------------------------------------------------------------------------------------------------
>>>                 Key: DERBY-2060
>>>                 URL: http://issues.apache.org/jira/browse/DERBY-2060
>>>             Project: Derby
>>>          Issue Type: Bug
>>>          Components: Documentation
>>>            Reporter: Bernt M. Johnsen
>>>         Assigned To: Kim Haase
>>>         Attachments: DERBY-2060.diff, DERBY-2060.zip
>>> On SET CURRENT ISOLATION statement in the Derby refernce manual:
>>> "Issuing this command commits the current transaction, which is consistent with
the java.sql.Connection.setTransactionLevel method."
>>> The correct method name is java.sql.Connection.setTransactionIsolation (java.sql.Connection.setTransactionLevel
does not exist)
>>> BTW: setTransactionIsolation will commit the current transaction if called in
the client driver but not in the embedded driver. See DERBY-638
>> -- 
>> This message is automatically generated by JIRA.
>> -
>> If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
>> -
>> For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message