Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <21483075.1172675757153.JavaMail.jira@brutus>
Date: Wed, 28 Feb 2007 07:15:57 -0800 (PST)
From: "Julius Stroffek (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-2360) The XAResource.end(xid,
 XAResource.TMFAIL) throws an exception
In-Reply-To: <23332615.1171970225528.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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