db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Deepa Remesh (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-1148) Client XA getTransactionIsolation() does not return the correct isolation level when rejoining a global transaction
Date Wed, 17 May 2006 18:18:07 GMT
     [ 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


Mime
View raw message