6 Replies Latest reply on Mar 20, 2009 12:09 PM by Clebert Suconic

    Few XA Questions...

    Clebert Suconic Master

      - In what circunstance xaSession.end(xid, XAResource.TMFAIL) would be called?

      I have made this simple test. and I would expect a commit call to a failed xaSession throwing an exception:

      public void testFailXID() throws Exception
       {
       Xid xid = newXID();
       ClientSession session = sessionFactory.createSession(true, false, false);
       session.start(xid, XAResource.TMNOFLAGS);
       session.end(xid, XAResource.TMFAIL);
       session.commit(xid, true); // shouldn't this throw an exception?
      
       session.close();
      
       }
      


      And this is more a question for TM guys:

      - In what cirscunstance xaSession.forget would be called by a transactionManager. I looked into Arjuna and I couldn't find it making that call anywhere.

      For JBossMessaging we are just ignoring the call (we couldn't find much use for it).

        • 1. Re: Few XA Questions...
          Tim Fox Master

           

          "clebert.suconic@jboss.com" wrote:
          - In what circunstance xaSession.end(xid, XAResource.TMFAIL) would be called?

          I have made this simple test. and I would expect a commit call to a failed xaSession throwing an exception:

          public void testFailXID() throws Exception
           {
           Xid xid = newXID();
           ClientSession session = sessionFactory.createSession(true, false, false);
           session.start(xid, XAResource.TMNOFLAGS);
           session.end(xid, XAResource.TMFAIL);
           session.commit(xid, true); // shouldn't this throw an exception?
          
           session.close();
          
           }
          


          And this is more a question for TM guys:


          I guess strictly we should be throwing an exception from commit since it should be rollback only, however in reality I suppose it would an error in the tx mgr if it called commit after ending with TMFAIL.

          • 2. Re: Few XA Questions...
            Jonathan Halliday Master

            forget is used to signal that a resource manager can throw away state relating to heuristically resolved transactions. For example, if you provide a management tool that allows transactions to be manually forced to commit or rollback, you need to remember the outcome and tell the transaction manager about it if asked. You can only throw away that knowledge when told to forget.

            end(TMFAIL);
            commit();

            is indeed an error on the part of the transaction manager. The commit should probably respond XA_RBROLLBACK if it's being polite, although XAER_PROTO would also be reasonable if it wants to signal that it's pissed of at being mistreated :-)

            • 3. Re: Few XA Questions...
              Clebert Suconic Master

               

              You can only throw away that knowledge when told to forget.



              So, if we commit the transaction through management, we shouldn't throw an exception if xa.commit(XID) is called.

              Say.. this pseudo test should work:

              management.commit(XID);

              tm.commit(xid);



              Is there a way to replicate this behaviour through Arjuna (making it call forget)?

              • 4. Re: Few XA Questions...
                Jonathan Halliday Master

                > So, if we commit the transaction through management, we shouldn't throw an exception if xa.commit(XID) is called.

                Wrong. XA_HEURCOM is what you need in that case.

                > Is there a way to replicate this behaviour through Arjuna (making it call forget)?

                yes. Take a look at the XARecoveryModule implementation.

                • 5. Re: Few XA Questions...
                  Tim Fox Master

                  Clebert - can you add a JIRA for this and we'll look at it after beta?

                  We just need to persist in the journal the list of heuristically committed and rolled back xids and load them on startup, so we can respond properly to the tx mgr/recovery manager.

                  We can also add a management method to list the lists of heuristically committed/rolledback xids