db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lily Wei (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-4314) With derby client setTransactionIsolation executes and commits even if isolation has not changed
Date Fri, 02 Apr 2010 18:12:27 GMT

     [ 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

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
        at org.apache.derby.client.net.NetXAResource.start(NetXAResource.java:64
        at org.apache.derbyTesting.functionTests.tests.jdbcapi.J2EEDataSourceTes
        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:

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
Exception in thread "main" org.apache.derby.shared.common.sanity.AssertFailure:
        at org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityMana
        at org.apache.derby.client.am.Connection.setTransactionIsolationX(Connec
        at org.apache.derby.client.am.Connection.setTransactionIsolation(Connect
        at org.apache.derby.client.am.LogicalConnection.setTransactionIsolation(
        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:,,,,,
>            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,
> 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.

View raw message