db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathey Marsden (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1148) Client XA getTransactionIsolation() does not return the correct isolation level when rejoining a global transaction
Date Wed, 17 May 2006 19:40:07 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1148?page=comments#action_12412233 ] 

Kathey Marsden commented on DERBY-1148:

Deepa said:
>The built-in function "CURRENT ISOLATION" is used for this.
I have a couple of concerns with this:
1)  Might the  VALUES CURRENT ISOLATION statement that is called upon getTransactionIsolation()
 cause a commit when autocommit is on?

2) I sem to recall a problem with setTransactionIsolationStmt that it was    not null but
not valid on  connection reset. But I don't see the bug or the fix. It might be good to null
out this variable in closeResourcesX() in addition to closing it.

>If we do not get the isolation from the server, we return what is stored in "isolation_"

Under what circumstances would we not get the isolation from the server. Might the value stored
in the isolation_ variable be wrong? If so it is better to throw an exception I think.

> Client XA getTransactionIsolation()   does not return the correct isolation level when
rejoining a global transaction
> ---------------------------------------------------------------------------------------------------------------------
>          Key: DERBY-1148
>          URL: http://issues.apache.org/jira/browse/DERBY-1148
>      Project: Derby
>         Type: Bug

>   Components: Network Client
>     Versions:
>     Reporter: Kathey Marsden
>     Assignee: Deepa Remesh
>      Fix For:
>  Attachments: SetIsolationUsingSQL.java, XACheckIsolation.java, XACheckIsolation_2.java,
derby-1148_v1.diff, derby-1148_v1.status
> When rejoining a global transaction, client does not report the correct isolation level
with a 
> getTransactionIsolation().    The server side isolation should be ok I think.
> This was discovered when testing the fix for DERBY-1044.  After the fix for DERBY-1044,
there is a new diff in the test, but the fix for DERBY-1044 just exposed this issue.  The
output for the test was correct before by circumstance.
> I will put comments with this bug in checkDataSource test.
> // now re-join the transaction, should pick up the read-only
> // and isolation level from the transaction,
> // holdability remains that of this handle.
> xar.start(xid, XAResource.TMJOIN);
> printState("re-join X1", cs1);
> xar.end(xid, XAResource.TMSUCCESS);

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message