[
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.
