[ 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
