db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Deepa Remesh (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-1148) Client XA getTransactionIsolation() does not return the correct isolation level when rejoining a global transaction
Date Tue, 23 May 2006 21:03:32 GMT
     [ http://issues.apache.org/jira/browse/DERBY-1148?page=all ]

Deepa Remesh updated DERBY-1148:
--------------------------------

    Attachment: derby-1148-draft1.diff
                derby-1148-draft1.status

As Kathey pointed out, my previous patch changes getTransactionIsolation method and will cause
a commit when autocommit is on. So I am off to my first approach which solved one case where
transaction isolation was wrong. I am attaching a draft patch (not for commit) 'derby-1148-draft1.diff'
which does the following:

* Add a variable(xaTransactionIsolation_) to NetXACallInfo to store the transaction isolation
level used in the distributed transaction.

*. When "joining" a distributed transaction, get the isolation level from the callInfo and
use it to update the client connection's isolation level locally. Do not flow anything to
the server since the server uses the correct isolation level. This will make sure the client
reports the same isolation that is used by the server. Before updating the connection's isolation
level, store it in a temporary variable so that we can use it restore the isolation level
when the distributed transaction ends.

*. When ending the distributed transaction, store the isolation level used in the distributed
transaction in the callInfo. Restore the connection's transaction isolation only if we had
changed it (when we joined the global transaction). 

But it does not solve all cases in checkDataSource test. I would like to solve the general
problem which is not specific to XA - "isolation_" stored in client's connection object can
get out of sync with the actual isolation. This will solve all issues in the client driver
in this area. Looking for some solution similar (but without the side effects) of what I tried
in my previous patch 'derby-1148_v1.diff'. As I have'nt found any, I am going back to my first
 approach which partly solves the XA problem. Any suggestions/feedback are welcome.

> 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: 10.2.0.0
>     Reporter: Kathey Marsden
>     Assignee: Deepa Remesh
>      Fix For: 10.2.0.0
>  Attachments: SetIsolationUsingSQL.java, XACheckIsolation.java, XACheckIsolation_2.java,
derby-1148-draft1.diff, derby-1148-draft1.status, 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:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message