db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julius Stroffek (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2360) The XAResource.end(xid, XAResource.TMFAIL) throws an exception
Date Wed, 28 Feb 2007 15:15:57 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476609
] 

Julius Stroffek commented on DERBY-2360:
----------------------------------------

The code in NetXAResource.end interprets the specification the same way as Geronimo and ObjectWeb.
At the end of the method there is a code

        if (rc != XAResource.XA_OK) {
            throwXAException(rc, false);
        }else {
        	conn_.setXAState(Connection.XA_T0_NOT_ASSOCIATED);
        } 
 
which do not set the proper xa state on a connection if the exception is thrown when TMFAIL
is specified.

I would say that the transaction state should not be returned to the client/transaction manager
as an exception at all. The exceptions should be thrown only as a result of an error of ending
the association itself.

The JTA spec says:
Error return values that are caused by the transaction manager's improper
handling of the XAResource object are mapped to Java exceptions via the
XAException class.

The JDK6 javadoc says (XAResource.end method):
Throws:
    XAException - An error has occurred. Possible XAException values are XAER_RMERR, XAER_RMFAILED,
XAER_NOTA, XAER_INVAL, XAER_PROTO, or XA_RB*.

I think that many developers (including myself before considering Dan's comment and reading
the DTP XA specification again) would interpret this as: "The exception is thrown so the error
disassociating the transaction from the connection occured".

So there are two possible interpretations:
1.) Map the return values from DTP XA spec and throw them as exceptions.
        * Doing this is not explicitly stated in JTA spec.
        * One have to use a bit of creativity to make a link between JTA and DTP XA specs.
        * Very less developers would interpret JTA spec. and javadoc this way.

2.) Throw an exception only if an error occured.
        * Follows the java convention for using exceptions.
        * More accurate to JTA spec without reading DTP XA.
        * Probably more developers will interpret JTA spec. and javadoc this way.

I would prefer the option 2.)

Please, provide any comments.


> The XAResource.end(xid, XAResource.TMFAIL) throws an exception
> --------------------------------------------------------------
>
>                 Key: DERBY-2360
>                 URL: https://issues.apache.org/jira/browse/DERBY-2360
>             Project: Derby
>          Issue Type: Bug
>    Affects Versions: 10.3.0.0
>         Environment: Solaris Nevada build 56, sun jdk 1.6
>            Reporter: Julius Stroffek
>         Assigned To: Julius Stroffek
>
> If I execute this peace of code
>         Xid xid = createXid(9,11);
>         xaRes.start(xid, XAResource.TMNOFLAGS);
>         Statement stm = conn.createStatement();
>         stm.execute("create table NumberTable2 (i int)");
>         stm.execute("insert into NumberTable2 values (1)");
>         xaRes.end(xid, XAResource.TMFAIL);
>         xaRes.rollback(xid);
> I get the following exception
> 1) testXAConnection(org.apache.derbyTesting.functionTests.tests.jdbcapi.XATransactionTest)javax.transaction.xa.XAException
>         at org.apache.derby.jdbc.EmbedXAResource.end(EmbedXAResource.java:208)
>         at org.apache.derbyTesting.functionTests.tests.jdbcapi.XATransactionTest.testXAConnection(XATransactionTest.java:94)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76)
>         at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
>         at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
>         at junit.extensions.TestSetup.run(TestSetup.java:25)
>         at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
>         at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
>         at junit.extensions.TestSetup.run(TestSetup.java:25)
>  
> If I change TMFAIL to TMSUCCESS, everything works. The end with TMFAIL shoudl do the
same as with TMSUCCESS except that I can only rollback the transaction.

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