db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathey Marsden (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4314) With derby client setTransactionIsolation executes and commits even if isolation has not changed
Date Mon, 26 Apr 2010 18:41:33 GMT

    [ https://issues.apache.org/jira/browse/DERBY-4314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12861038#action_12861038
] 

Kathey Marsden commented on DERBY-4314:
---------------------------------------

I think the more relevant failure is the first one that occurs:

1) testGlobalLocalInterleaf(org.apache.derbyTesting.functionTests.tests.jdbcapi.
J2EEDataSourceTest)junit.framework.AssertionFailedError: expected:<1> but was:<2
>
        at org.apache.derbyTesting.functionTests.tests.jdbcapi.J2EEDataSourceTes
t.assertConnectionState(J2EEDataSourceTest.java:3341)
        at org.apache.derbyTesting.functionTests.tests.jdbcapi.J2EEDataSourceTes
t.testGlobalLocalInterleaf(J2EEDataSourceTest.java:1501)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:48)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:37)
        at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:
109)
        at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
        at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
        at junit.extensions.TestSetup.run(TestSetup.java:23)
        at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57
)
        at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
        at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
        at junit.extensions.TestSetup.run(TestSetup.java:23)
        at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
        at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
        at junit.extensions.TestSetup.run(TestSetup.java:23)
        at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57


Around line 1406 we end a global transaction:
   assertConnectionState(
            ResultSet.CLOSE_CURSORS_AT_COMMIT, 
            Connection.TRANSACTION_READ_UNCOMMITTED,
            false, ReadOnly, cs1);
        
        xar.end(xid, XAResource.TMSUCCESS);


Then we get a new logical connection in between (with isolation READ_COMMITTED) and then

about 1499 we join the global transaction
     xar.start(xid, XAResource.TMJOIN);
        cs1 = xac.getConnection();
        // re-join with new handle X1
        assertConnectionState(
            ResultSet.CLOSE_CURSORS_AT_COMMIT, 
            Connection.TRANSACTION_READ_UNCOMMITTED,
            false, ReadOnly, cs1);

But we get the error 
J2EEDataSourceTest)junit.framework.AssertionFailedError: expected:<1> but was:<2
>
So the isolation level was not restored to READ_UNCOMMITED when we joined.   I haven't looked
at the patch, but I think this is the issue that would be best to look at first. I think the
DUPID error may be just a cascading failure that occurs because of this one.



> With derby client setTransactionIsolation executes and commits even if isolation has
not changed 
> -------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-4314
>                 URL: https://issues.apache.org/jira/browse/DERBY-4314
>             Project: Derby
>          Issue Type: Improvement
>          Components: JDBC, Network Client
>    Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.3.0, 10.4.2.0, 10.5.1.1, 10.6.0.0
>            Reporter: Kathey Marsden
>            Priority: Minor
>         Attachments: DERBY-4314-2.diff, DERBY-4314-3.diff, DERBY-4314-5.diff, derby-4314-6a-initial_piggybacking.diff,
derby-4314-6a-initial_piggybacking.stat, DERBY-4314-6b-combinepiggybacking.diff, DERBY-4314-6c-combineaftermerge.diff,
DERBY-4314.diff, TestConnReuse.java
>
>
> With in EmbedConnection.setIsolation() we have a check to see if the isolation level
is the same and if so just return without doing a commit:
>   public void setTransactionIsolation(int level) throws SQLException {
> 		if (level == getTransactionIsolation())
> 			return;
> with org.apache.derby.client.am.Connection we have no such check. It would be good if
the client driver acted like embedded.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message