5 Replies Latest reply on Jun 7, 2006 6:25 AM by Mark Little

    Exceptionhandling in distributed transactions

    Peter Potthoff Newbie

      Hello,

      I have installed JBossTS 4.2 into jboss-4.0.3SP1 using the instructions
      in the INSTALL file that comes with JBossTS and configured the interposition
      interceptor in iiop-service.xml.
      After booting the "all" configuration I tried to run the following exception
      test:

      My client calls a StatelessSessionBean which in turn calls another
      StatelessSessionBean on a different JBoss instance. The last one obtains a
      UserTransaction-Object, calls setRollbackOnly and throws a UserException.
      ( simple exceptionclass derived from java.lang.Exception )

      The Exception unwinds the callgraph to the TxInterceptorCMT of the first
      instance ( all my beans use container managed transactions ) where the
      interceptor queries the state of the TX and gets the result TRANSACTION_ACTIVE.
      Due to this result the interceptor tries to commit the TX and receives a
      RollbackException from the TX-Coordinator which in turn is reflected to the
      client. The whole TX is rolled back but original UserException gets lost.

      If I call setRollbackOnly and throw the UserException in the first SessionBean,
      the interceptor will detect the TX state STATUS_MARKED_ROLLBACK and rolls back
      the exception. The UserException will be reflected to the clientapplication
      as expected.

      Is this behaviour a bug or do I have to handle the UserTransaction in the
      first SessionBean and call setRollbackOnly manually?

      Thanks,
      Peter

      PS.:
      When looking into the source code of the arjuna packages I found a
      lot of exceptionhandlers that catch an original exception and throw
      a new exception without logging or chaining them. The original reason
      will be lost in such case.
      ( e.g. com.arjuna.ats.internal.jta.transaction.jts.TransactionManagerImple )

        • 1. Re: Exceptionhandling in distributed transactions
          Mark Little Master

           

          "peter_p" wrote:
          Hello,

          I have installed JBossTS 4.2 into jboss-4.0.3SP1 using the instructions
          in the INSTALL file that comes with JBossTS and configured the interposition
          interceptor in iiop-service.xml.


          Hopefully you either mean JBossTS 4.2.1Beta 1, or that you used the installation instructions on the download page, as it clearly states on the download page?


          PS.:
          When looking into the source code of the arjuna packages I found a
          lot of exceptionhandlers that catch an original exception and throw
          a new exception without logging or chaining them. The original reason
          will be lost in such case.
          ( e.g. com.arjuna.ats.internal.jta.transaction.jts.TransactionManagerImple )


          Thanks, we'll take a look. Depends what you mean by "a lot", but the code's been around for 10 years and obviously some things get overlooked. However, in the case of JTS, it's often impossible to chain exceptions because the CORBA binding doesn't support them.

          • 2. Re: Exceptionhandling in distributed transactions
            Mark Little Master

            In the case of a distributed transaction, if you mark a downstream node as rollback-only, the specifications (OTS in this case) don't require that this fact is propagated throughout all of the other nodes. All that is required is that the outcome of the transaction will ultimately be to roll back. Calls to getStatus within a process for a distributed transaction are ultimately a snapshot of the local state of the transaction and you cannot infer from that the global status.

            • 3. Re: Exceptionhandling in distributed transactions
              Peter Potthoff Newbie

              Thank you for the quick reply.

              Hopefully you either mean JBossTS 4.2.1Beta 1, or that you used the installation instructions on the download page, as it clearly states on the download page?


              No, I installed the package JBossTS 4.2 some weeks ago. It works fine using the interposition interceptor.
              Do you think I should give 4.2.1 Beta 1 a try, will it have another behaviour in exception handling?

              Calls to getStatus within a process for a distributed transaction are ultimately a snapshot of the local state of the transaction and you cannot infer from that the global status.


              Ok, I see but what about the lost of information from the clients point of view?
              Would it be possible for the method endTransaction of TxInterceptorCMT to chain the original exception
              with the new generated RollbackException and reflect both exceptions to the client?

              In my opinion this would be a great benefit for the client because the error message would be more precise.


              • 4. Re: Exceptionhandling in distributed transactions
                Mark Little Master

                 

                "peter_p" wrote:
                Thank you for the quick reply.

                Hopefully you either mean JBossTS 4.2.1Beta 1, or that you used the installation instructions on the download page, as it clearly states on the download page?


                No, I installed the package JBossTS 4.2 some weeks ago. It works fine using the interposition interceptor.
                Do you think I should give 4.2.1 Beta 1 a try, will it have another behaviour in exception handling?


                No, it won't have any affect on this, but there are some known issues with JacORB that are fixed if you follow the other instructions for 4.2: you don't need to move to 4.2.1 unless you want Web Services transactions support.


                Calls to getStatus within a process for a distributed transaction are ultimately a snapshot of the local state of the transaction and you cannot infer from that the global status.


                Ok, I see but what about the lost of information from the clients point of view?


                Getting a global picture of events in a distributed system is complex and trade-offs need to be made. We could look at propagating more information back to the client, but as long as we log reasons somewhere in the system (e.g., at the point the problem happened) you can find out eventually. To be honest, many of our customers over the years are more interested in faulting and trying again as quickly as possible within their applications and dealing with permanent/repeated errors off-line by checking system logs.


                Would it be possible for the method endTransaction of TxInterceptorCMT to chain the original exception
                with the new generated RollbackException and reflect both exceptions to the client?

                In my opinion this would be a great benefit for the client because the error message would be more precise.


                We'd have to see: as I said before, if you're using OTS then chaining of exceptions may not be possible. We can certainly look at it for a subsequent release.