[ http://issues.apache.org/jira/browse/DERBY-1148?page=all ]
Deepa Remesh updated DERBY-1148:
--------------------------------
Attachment: derby-1148_v1.diff
derby-1148_v1.status
SetIsolationUsingSQL.java
Attaching a patch 'derby-1148_v1.diff' which changes the
getTransactionIsolation method in client's Connection class to get the
transaction isolation from the server. This patch solves both DERBY-1148 and
DERBY-1053. I found these issues are specific cases of a more general problem
-----"isolation_" stored in client's connection object can get out of sync with
the actual isolation e.g., when in an XA transaction, when isolation is set
using SQL instead of JDBC.
I am also attaching a repro 'SetIsolationUsingSQL.java' which shows this
problem is not limited to XA. To run this repro, start network server on port
1527, and run 'java SetIsolationUsingSQL'. Without the patch, the isolation
level reported by client is wrong when SQL is used to set it.
In my previous comment, I had mentioned I tried to solve this problem by trying
to store the isolation used in the distributed transaction in NetXACallInfo.
This solved one case but for other cases, I tried to change client's XA and did
not find much success. Also, I found that this a generic problem. So the patch
I am uploading takes a completely different approach.
Summary of patch:
* Changes getTransactionIsolation method in
org.apache.derby.client.am.Connection class to get the isolation level from
server. The built-in function "CURRENT ISOLATION" is used for this. If we do
not get the isolation from the server, we return what is stored in "isolation_"
variable. Is this okay or should we throw an exception if we do not get the
isolation level from the server?
* Removes the excludes for DERBY-1148 and DERBY-1035 from checkDataSource test.
* Adds a test for transaction suspend/resume in checkDataSource test.
* Adds exclusions for DERBY-1325. These cases were coincidentally correct
before this patch. However, the actual isolation used at server was wrong
(mentioned as problem 2 in previous comments). This is fixed in DERBY-1325. I
have a patch uploaded to DERBY-1325 which has become out of sync. When I upload
the new patch, I will remove these exclusions and verify that problem 2 is
solved. I will also upload a small write-up which summarizes the isolation
level changes across transaction boundaries.
* Updates master files
This patch modifies client code and the checkDataSource tests. With this patch,
I have run derbynetclientmats using Sun jdk 1.4.2 on Windows XP. I have also
run the changed tests jdbcapi/checkDataSource.java and
jdbcapi/checkDataSource30.java in embedded framework. Please take a look at
this patch and provide feedback. Thanks.
> 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_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
