[ http://issues.apache.org/jira/browse/DERBY-1148?page=all ]
Deepa Remesh updated DERBY-1148:
--------------------------------
Attachment: XACheckIsolation_2.java
Attaching an updated repro with cases for suspend/resume of a transaction.
These were also behaving wrongly with the client. I'll add these cases to
checkDataSource test.
> 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, XACheckIsolation_2.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
