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

Reply via email to