[
https://issues.apache.org/jira/browse/DERBY-4314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lily Wei updated DERBY-4314:
----------------------------
Attachment: TestConnReuse.java
DERBY-4314-6b-combinepiggybacking.diff
After careful review the code, I think there might be some issue relate to DRDA
protocal with the patch. When running suites.all test suite,
testSetIsolationWithStatement failed with the following assertion:
There was 1 error:
1) testSetIsolationWithStatement(org.apache.derbyTesting.functionTests.tests.jdb
capi.J2EEDataSourceTest)org.apache.derby.client.am.XaException: XAER_DUPID : Err
or executing a XAResource.start(), server returned XAER_DUPID.
at org.apache.derby.client.net.NetXAResource.throwXAException(NetXAResou
rce.java:756)
at org.apache.derby.client.net.NetXAResource.start(NetXAResource.java:64
7)
at org.apache.derbyTesting.functionTests.tests.jdbcapi.J2EEDataSourceTes
t.testSetIsolationWithStatement(J2EEDataSourceTest.java:1623)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:
109)
Looking at NetXAResource.start with Xid xid2 = new cdsXid(1, (byte) 93, (byte)
103);
xar.start(xid2, XAResource.TMNOFLAGS); on J2EEDataSourceTest, I am
thinking it might be relate to change of behavior of DRDA protocal. I need to
further investigate on this.
With repro on Derby-4343 (Please refer to second attachment file
TestConnReuse.java), if the third connection does not set the transaction
isolation level to Connection.TRANSACTION_READ_COMMITTED but
Connection.TRANSACTION_READ_UNCOMMITTED, we can get third connection without
assertion.
This is the assertion trace if the third connection set the
transcationIsolation to Connection.TRANSACTION_READ_COMMITTED.
Exception in thread "main" org.apache.derby.shared.common.sanity.AssertFailure:
ASSERT FAILED
at org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityMana
ger.java:98)
at org.apache.derby.client.am.Connection.setTransactionIsolationX(Connec
tion.java:987)
at org.apache.derby.client.am.Connection.setTransactionIsolation(Connect
ion.java:915)
at org.apache.derby.client.am.LogicalConnection.setTransactionIsolation(
LogicalConnection.java:253)
at TestConnReuse.main(TestConnReuse.java:33)
Any guideline on the cause of reason is highly appreciated.
> 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.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.
