1 2 Previous Next 21 Replies Latest reply on May 22, 2013 8:52 AM by Paul Robinson Go to original post
      • 15. Re: JTA 1.2 Implementation Work
        Paul Robinson Master

        Tom,

         

        Re: When something goes wrong internally to the implementation of the TransactionInterceptor or TransactionalContext, what RuntimeException should I throw?

        It doesn't seem to be specified, so I'm thinking I can just throw some Narayana specific RuntimeException.

         

        Can you provide an example, at the moment I am thinking javax.transaction.TransactionalException (from 3.7: Transactional Annotation)

        Yes, I think I can use TransactionalException in the transaction interceptors. However, I was more thinking about what to do in the TransactionalContext. Here's an example:

         

        The TransactionalContext needs to lookup the transaction manager. If this fails, a javax.transaction.SystemException is thrown. This has to be handled (it extends Exception) and the Context interface does not declare that any checked exceptions can be thrown from its methods. Therefore I need to wrap the javax.transaction.SystemException in some unchecked transaction.

         

        TransactionalException is the only RuntimeException in the JTA 1.2 spec, so I'll just use whatever general unchecked exception we use in the JTA 1.1 implementation.

        • 16. Re: JTA 1.2 Implementation Work
          Mark Little Master

          As soon as WF moves to adopt EE7 for all of its constituent components then JTA 1.2 should be the default.

          • 17. Re: JTA 1.2 Implementation Work
            Paul Robinson Master

            Mark,

             

             

            Mark Little wrote:

             

            What I said was only partially correct. We call end on suspended RMs if delist hasn't been called. Having this happen for all RMs is easy, but we'd have to be aware of interface changes and semantic changes, since it is not backwardly compatible *unless* we have this as a configurable option. Worth considering though, since JTA 1.2 adoption will take a while.

             

            Mike and I have looked over the code, and we think that we already comply to this spec point. Take a look at the explanation I added to the "Other Spec Changes" section.

            • 18. Re: JTA 1.2 Implementation Work
              Tom Jenkinson Master

              Paul Robinson wrote:

               

              Mark,

               

               

              Mark Little wrote:

               

              What I said was only partially correct. We call end on suspended RMs if delist hasn't been called. Having this happen for all RMs is easy, but we'd have to be aware of interface changes and semantic changes, since it is not backwardly compatible *unless* we have this as a configurable option. Worth considering though, since JTA 1.2 adoption will take a while.

               

              Mike and I have looked over the code, and we think that we already comply to this spec point. Take a look at the explanation I added to the "Other Spec Changes" section.

              I have taken a look at this too and agree XAResource::end(TMSUCCESS) does seem to be called in all permutations. I wonder if TMFAIL might be more appropriate for topLevelAbort? However, I open this as a point of discussion, rather than suggestion. In practical terms I suspect it won't make any difference to the RM.

               

              Also, your description in "Other Spec Changes" omits the fact that  com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple::rollback(), endSuspendedRMs() is also invoked. Near as I can work out though, endSuspendedRMs is almost superflous as topLevel* will end ASSOCIATION_SUSPENDED branches anyway?

              • 19. Re: JTA 1.2 Implementation Work
                Paul Robinson Master

                Thanks Tom,

                Tom Jenkinson wrote:

                 

                Also, your description in "Other Spec Changes" omits the fact that  com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple::rollback(), endSuspendedRMs() is also invoked.

                 

                Updated.

                 

                Tom Jenkinson wrote:

                 

                Near as I can work out though, endSuspendedRMs is almost superflous as topLevel* will end ASSOCIATION_SUSPENDED branches anyway?

                 

                It seems that way to me, but I may well be missing some corner-case.

                • 20. Re: JTA 1.2 Implementation Work
                  Mark Little Master

                  No code changes for this is even better then It has been a while since that code was written

                  • 21. Re: JTA 1.2 Implementation Work
                    Paul Robinson Master

                    Mark,

                    Mark Little wrote:

                     

                    No code changes for this is even better then It has been a while since that code was written

                    Yes, that pleased me too!

                     

                    Thanks for checking.

                    1 2 Previous Next