[ 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
