You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Deepa Remesh (JIRA)" <de...@db.apache.org> on 2006/04/27 21:36:38 UTC
[jira] Updated: (DERBY-1148) Client XA getTransactionIsolation()
does not return the correct isolation level when rejoining a global
transaction
[ http://issues.apache.org/jira/browse/DERBY-1148?page=all ]
Deepa Remesh updated DERBY-1148:
--------------------------------
Attachment: XACheckIsolation.java
Kathey mentioned the problem could be in reporting of isolation level by client. So I was trying to check that the isolation level at the server is correct. To check this, I created a smaller repro (XACheckIsolation.java) with a part of the checkDataSource test. In the test, I added calls to a stored procedure which checks the isolation level of a nested connection. From the results, it seems to me the server-side isolation is correct when rejoining a global transaction. It is only the return value of getTransactionIsolation in client driver which is wrong. However, the switch from global back to local does not seem to restore the isolation level in the server. Here are the outputs of running the attached repro. I have added my comments starting with ----> as to what I think the problem is:
---------------------------------------------------------------------------------------------------------------------------------------
With client driver:
---------------------------------------------------------------------------------------------------------------------------------------
initial local
isolation level: READ_COMMITTED
initial X1
isolation level: READ_COMMITTED
modified X1
isolation level: READ_UNCOMMITTED
modified local
isolation level: READ_UNCOMMITTED
reset local
isolation level: READ_COMMITTED
re-join X1
isolation level: READ_COMMITTED ----> This is wrong. But isolation level in the server is correct.
back to local (same as reset)
isolation level: READ_COMMITTED
---------------------------------------------------------------------------------------------------------------------------------------
Corresponding server-side isolation (with client driver):
---------------------------------------------------------------------------------------------------------------------------------------
isolation level in procedure: READ_COMMITTED
isolation level in procedure: READ_COMMITTED
isolation level in procedure: READ_UNCOMMITTED
isolation level in procedure: READ_UNCOMMITTED
isolation level in procedure: READ_COMMITTED
isolation level in procedure: READ_UNCOMMITTED
isolation level in procedure: READ_UNCOMMITTED ----> This is wrong.
---------------------------------------------------------------------------------------------------------------------------------------
Output with embedded driver (for reference):
---------------------------------------------------------------------------------------------------------------------------------------
initial local
isolation level: READ_COMMITTED
isolation level in procedure: READ_COMMITTED
initial X1
isolation level: READ_COMMITTED
isolation level in procedure: READ_COMMITTED
modified X1
isolation level: READ_UNCOMMITTED
isolation level in procedure: READ_UNCOMMITTED
modified local
isolation level: READ_UNCOMMITTED
isolation level in procedure: READ_UNCOMMITTED
reset local
isolation level: READ_COMMITTED
isolation level in procedure: READ_COMMITTED
re-join X1
isolation level: READ_UNCOMMITTED
isolation level in procedure: READ_UNCOMMITTED
back to local (same as reset)
isolation level: READ_COMMITTED
isolation level in procedure: READ_COMMITTED
---------------------------------------------------------------------------------------------------------------------------------------
>From the test, I think there are two problems:
1. Isolation level reported by client driver is wrong. 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 global to local transaction, the isolation level does not get restored at the server.
I would appreciate if someone can go through the attached test and outputs and tell me if I have understood this correctly.
> 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