4 Replies Latest reply on Sep 12, 2002 7:57 PM by Kevin Turner


    Kevin Turner Newbie

      I have 3 stateless session beans defined with container managed transactions. My first session bean "A" calls methods on the other 2 session beans "B" and "C". The transaction attribute for methods defined in session bean "A" is "Required". Since this is the first session bean called, a new transaction should be created. The transaction attribute for session beans "B" and "C" is "RequiresNew". So, even though session bean "A" has its own transactional context, method invocations on session beans "B" and "C" should always create separate transactions.

      In session bean "A", I call method of session bean "B". This method is completed successfully so the transaction is committed. I then call method on session bean "C". This method fails and the transaction is rolled back. I then call method of session bean "B" which throws an XAException when attempting to acquire a database connection. So, I have transaction "1" for session bean "A", transaction "2" for session bean "B", transaction "3" for session bean "C", transaction "4" for session bean "B". Transactions "1", "3" and "4" all fail because of the failed transaction "3". Any subsequent attempt to acquire a database connection throws an XAException.

      Am I breaking any rules here or is this a bug? Any help would be greatly appreciated.

        • 1. Re: XAException
          Kevin Turner Newbie

          I have pasted a portion of the stack trace below. The error code is "XAER_NOTA" which means "The XID is not valid". Note that all transactions are committed successfully if the transaction for session bean "C" is successful. It's only when the session bean "C" transaction fails that I get the XAException.

          XAException: tx=XidImpl [FormatId=257, GlobalId=actek-kturner//3, BranchQual=] errorCode=XAER_NOTA
          at org.opentools.minerva.jdbc.xa.wrapper.XAResourceImpl.start(XAResourceImpl.java:258)
          at org.jboss.tm.TxCapsule.startResource(TxCapsule.java:1087)
          at org.jboss.tm.TxCapsule.enlistResource(TxCapsule.java:614)
          at org.jboss.tm.TransactionImpl.enlistResource(TransactionImpl.java:111)
          at org.jboss.pool.jdbc.xa.XAConnectionFactory.prepareObject(XAConnectionFactory.java:290)
          at org.jboss.pool.ObjectPool.getObject(ObjectPool.java:566)
          at org.jboss.pool.ObjectPool.getObject(ObjectPool.java:538)
          at org.jboss.pool.jdbc.xa.XAPoolDataSource.getConnection(XAPoolDataSource.java:178)
          at com.actek.j2ee.common.util.ConnectionFactory.getConnection(ConnectionFactory.java:47)
          at com.actek.j2ee.common.util.ConnectionFactory.getConnection(ConnectionFactory.java:78)
          at com.actek.j2ee.common.util.ConnectionFactory.getConnection(ConnectionFactory.java:67)

          • 2. Re: XAException
            Adrian Brock Master

            Which version of JBoss do you have, looks like 2.x?

            XAER_NOTA means an invalid XID (transaction id)

            it looks like the XID for the second invocation of B
            is the same as the XID for the failed transaction in C

            I'm guessing this from
            actek-turner//3 which suggests it is the third transaction

            Try configuring TRACE logging for
            this should show the transaction starts/commits/rollbacks
            unless you have an old version that didn't include
            this logging.


            • 3. Re: XAException
              Kevin Turner Newbie

              I am running JBoss 2.4.3 against SQLServer 2000 with Opta2000 4.14 JDBC driver. This may be a bug with the JDBC driver. I searched the revision history of the driver and 4.11 had this description:
              "The error 'The Xid is not valid.' with JBoss was fixed."

              Apparently it's not fixed for the scenario I described. This was logged to Opta support.

              I will try to set the log options to TRACE as you described. Thanks.

              • 4. Re: XAException
                Kevin Turner Newbie

                The problem was in my "DataSourceClass" attribute setting for my connection pool in the jboss.jcml file. I was using the old XA wrapper class "org.opentools.minerva.jdbc.xa.wrapper.XADataSourceImpl" instead of "org.jboss.pool.jdbc.xa.wrapper.XADataSourceImpl". When I changed this attribute, I no longer get the XAException.