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] Commented: (DERBY-1148) Client XA getTransactionIsolation() does not return the correct isolation level when rejoining a global transaction
Date Fri, 28 Apr 2006 17:31:39 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1148?page=comments#action_12376971 ] 

Deepa Remesh commented on DERBY-1148:
-------------------------------------

Currently, I am using what is implemented in embedded driver as my reference. JDBC 3.0 standard
mentions this: "Applications should also refrain from calling Connection.setTransactionIsolation
within the bounds of a distributed transaction. The resulting behavior is implementation-defined.".
I could not find any documentation which describes the Derby implementation. Is this documented
at some place? If not, I plan to write up the behaviour referring to what is done in the embedded
driver.

In my previous comment, I had identified two problems which I am restating (with some additions)
as follows:

1. Isolation level reported by client driver is wrong in some cases. This seems to be because
of the disconnect between the connection object states in the client and the server.
2. With client driver, when switching from a global transaction (which we joined) to a local
transaction, the isolation level does not get restored at the server.  In this case, the isolation
level of the local transaction should be restored to what it was before joining the global
transaction.

Assuming I have understood the problem correctly, here is what I have done so far for problem#
1 :

* 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).

I have run my repro with these code changes and verified that the transaction isolation reported
by client in various cases is okay. I also need to understand the behaviour when we resume
a suspended transaction and run more tests. I am puzzled by problem 2 and need to look at
it in more detail. Meanwhile, I would appreciate any feedback on this.

> 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: XACheckIsolation.java
>
> 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