8 Replies Latest reply on Jun 26, 2003 10:42 AM by Tal

    Two Phase Commit question

    Tal Newbie

      Hi,

      I'm writing a RA that connects to a remote transaction system.

      On the remote transaction system I wrote a CRM (Communications Resource Manager) that wills serve as an agent to the TM.

      I ran some simulations on jboss, accessing two transactions in the same global transaction. both voted XA_OK on the prepare.
      when the commit for the first branch was called, it returned XA_RETRY (4) since the CRM on the remote machine was temporarily unavailable.

      The TM, ignored it, and it called Commit on the other branch, and then forget on the branch that asked for a retry.

      is it the RM responsibility to log the decision to commit the transaction, and to do it in it's one will? if that's true, is there a logging service that i can utilize in jboss to persistently store the decisions?

      Also, I'm not sure why it called the forget method. suppose I was going to harden the decision to commit the transaction on the entry to the commit method, but failed to access the log. the transaction on the remote system will get to in-doubt state. i will never know whether to commit it or to toll it back.

      so bottom line questions:
      1. is it the RM responsibilty to harden the commit and rollback decisions?

      2. if so, is there a mechanism in jboss that i can reuse

      3. when does jboss TM call the recover method. couldn't get that to happen....

      Thanks,
      Tal

        • 1. Re: Two Phase Commit question
          Adrian Brock Master

          The default TM included in jboss does not log
          transactions. It therefore does not do recovery.

          XA_RETRY is not in the spec, but it is in the javadoc.
          I noticed some TMs have a policy for forgetting
          heuristic commits which is what the jboss TM does without any policy configuration.

          There is a logging TM being developed for jboss4,
          the support for XA_RETRY has not changed.

          Regards,
          Adrian

          • 2. Re: Two Phase Commit question
            Tal Newbie

            Thanks.

            The XA_RETRY is not in the JTA spec, but it is in the X/Open XA Spec. (page 33).

            and it says:
            "... The transaction manager should reissue xa_commit() at a later time."

            • 3. Re: Two Phase Commit question
              Adrian Brock Master

              The X/Open spec is part of the JTA spec by reference.

              Regards,
              Adrian

              • 4. Re: Two Phase Commit question
                Tal Newbie

                So does it mean that JBoss is not JTA compliant?

                • 5. Re: Two Phase Commit question
                  Adrian Brock Master

                  Yes, the TM included with jboss doesn't log
                  transactions so it cannot recover() or retry the
                  commit() later.

                  The javadocs for XA_RETRY say the operation
                  maybe retried?

                  Regards,
                  Adrian

                  • 6. Re: Two Phase Commit question
                    Kevin Birch Newbie

                    This is an excellent question. I believe the answers are:

                    1. Yes and No. No in that the RM is responsible for guranteeing that commit would or would not succeed by given the proper response from the prepare method. If a commit cannot succeed, then an XA_RETRY exeption should be thrown. Note that JBoss does not support retries though, so it's a delima. However, the wording on the spec on this matter is not very stong either:

                    "The resource manager is not able to commit the transaction branch at this time. [...] All resources held on behalf of *xid remain in a prepared state until commitment is possible. The transaction manager should reissue xa_commit() at a later time."

                    The word "should" means something very different than "must", so JBoss may be compliant by doing nothing, but just not very useful.

                    However, the answer is also yes because the X/Open spec states that the RM is required have access to persistent storage for the Xid's it is tracking during 2PC. This is how recovery is supported. The important thing is that any persisting has happend in prepare, before commit or rollback are called.

                    2. You could possible use the LoggingTxLogger or NIOMMLogPair classes, but I'm not sure they would be right for your needs.

                    3. The recover method is called during application server crash recovery. In order for this to be invoked, you would have to kill the app server when a global tx is in progress. The out-of-the box configuration of JBoss 4.0 doesn't use the recoverable transaction manager component, so that would need to be configured. I'm not exactly sure how that is done, maybe someone else knows?

                    cheers,
                    kevin

                    • 7. Re: Two Phase Commit question
                      Adrian Brock Master

                      I haven't really looked at the new TM in jboss4.

                      Since it is an MBean it should be possible to
                      list retryable transactions and allow them
                      to be completed. You could even schedule it.

                      I would expect your resource manager to also
                      provide this feature. There could be occasions
                      where the TM's peristent store is lost
                      or the TM was not able to contact the resource
                      manager for an extended period, you
                      need some mechanism to fix the in doubt transaction
                      locally.

                      Regards,
                      Adrian

                      • 8. Re: Two Phase Commit question
                        Tal Newbie

                        Thanks,

                        The RM does persist that information on the host side (the communications RM does that by talking with the local (host) TM ) and it does provide mechanism to resolve in-doubt transactions locally.

                        The question is whether the RM part that runs inside the app. server (RA) should keep a persistent log as well.
                        (meaning that for each transaction, 3 persistent logs will be used:
                        1- the app. server's TM log
                        2- the RA log
                        3- the CRM log
                        )

                        very fast it wont be....

                        Tal