Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <24090568.1148584531121.JavaMail.jira@brutus>
Date: Thu, 25 May 2006 19:15:31 +0000 (GMT+00:00)
From: "Deepa Remesh (JIRA)" <derby-dev@db.apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Updated: (DERBY-1148) Client XA getTransactionIsolation()
   does not return the correct isolation level when rejoining a global
 transaction
In-Reply-To: <1217827366.1143164722090.JavaMail.jira@ajax>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

     [ http://issues.apache.org/jira/browse/DERBY-1148?page=all ]

Deepa Remesh updated DERBY-1148:
--------------------------------

    Attachment: derby-1148_v2.diff
                derby-1148_v2.status
                XA_TransactionIsolation.html

I am attaching another patch 'derby-1148_v2.diff' which is based on proposal 2 ----  change the getTransactionIsolation method in client's Connection class to get the transaction isolation from the server. It addresses Kathey's concern of auto-commit by changing/restoring auto-commit inside the method call. 
I have tried to address all comments from Kathey in this patch.

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. It throws SQLException in case of failures. At the start of the method, the current auto-commit value is stored in a variable. When executing the function, auto-commit is set to false. At the end of the method, auto-commit value is restored. As it is the client which drives the auto-commit, this strategy of locally changing the auto-commit works. 

* Removes the excludes for DERBY-1148 and DERBY-1035 from checkDataSource test. Adds a test for transaction suspend/resume in checkDataSource test. Updates master files 

With this patch, I have run derbynetclientmats with Sun jdk 1.4.2 on Windows XP. I also ran checkDataSource.java and checkDataSource30.java with embedded and client framework. No failures. Please take a look at this patch and provide feedback.

If this change looks okay, it will solve both DERBY-1148 and DERBY-1035. Sorry for going back and forth between the proposed solutions. As I mentioned earlier, solving the general problem seems better than trying to address individual cases. I have also attached a small write-up 'XA_TransactionIsolation.html' based on my understanding of how isolation levels change across transaction boundaries.

> 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, XA_TransactionIsolation.html, derby-1148-draft1.diff, derby-1148-draft1.status, derby-1148_v1.diff, derby-1148_v1.status, derby-1148_v2.diff, derby-1148_v2.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