Thank you very much, Bernt -- I appreciate the clarifications.
I will document the current behavior now, and leave you to file an issue
to describe the needed changes. It sounds as if, among other things, the
statement needs a new name: SET TRANSACTION ISOLATION.
Kim
Bernt M. Johnsen wrote:
Kim Haase wrote (2006-11-29 11:31:52):
Do you mean SET ISOLATION rather than SET TRANSACTION? (I don't have
access to the SQL 2003 standard.)
According to the SQL standard, the syntax should be SET TRANSACTION
ISOLATION...
In Derby this is implemented as SET CURRENT ISOLATION.....
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.
Yes. Actually we have 3 alternatives on this
1) Change network client driver behaviour to be like the embedded
driver ,
2) change embedded driver behaviour to be like the client driver, or
3) change Derby to be compliant with the SQL standard
I prefer 3.
2) Should we document the current behavior in the meantime, while
waiting for the fixes?
Yes, I think so.
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.
That is my understanding of the current sematics.
