3 Replies Latest reply on Sep 20, 2001 4:26 PM by pra

    dealing with rollbacks and stuff

    fstarsinic

      I have written a generic MDB. When it recieves
      a message (an object message), it looks up in an
      XML file the "activities" that it needs to
      execute based on a parameter that gets passed in the message.

      If an activity fails, then the
      MDB fails and the message gets requeued.

      This basically puts the app server into an infinite loop. Are there parameters that allow how soon
      a message gets requeued or how many times it will be
      requeued?

      Is anyone else doing this sort of thing. i'm interested in how to best handle
      exception handling within the MDB. If there are 8
      activities for a given message, how best do i handle
      making sure each one gets executed eventually or even better yet, that no activity gets executed twice.

      ... that sort of thing :)

      thanks,

      frank

        • 1. Re: dealing with rollbacks and stuff

          > I have written a generic MDB. When it recieves
          > a message (an object message), it looks up in an
          > XML file the "activities" that it needs to
          > execute based on a parameter that gets passed in the
          > message.
          >
          > If an activity fails, then the
          > MDB fails and the message gets requeued.
          >
          > This basically puts the app server into an infinite
          > loop. Are there parameters that allow how soon
          > a message gets requeued or how many times it will be
          > requeued?

          No there is not. Up to 2.4.1 you will fall into an endless loop if you do not handle your messages.

          In 3.0 there is a Dead Letter Queue where messages recent a certain amount of times wil be sent to.

          //Peter
          >
          > Is anyone else doing this sort of thing. i'm
          > interested in how to best handle
          > exception handling within the MDB. If there are 8
          > activities for a given message, how best do i handle
          > making sure each one gets executed eventually or even
          > better yet, that no activity gets executed twice.
          >
          > ... that sort of thing :)
          >
          > thanks,
          >
          > frank

          • 2. Re: dealing with rollbacks and stuff
            aglover

            Peter,
            what do you mean by handling messages? If one has a try/catch block in the onMessage() method and an exception is thrown, does this mean the transaction is rolled back or that some how the message is requeued?
            If this is indeed the case, would you recommend BMP so that the MDB could commit the transaction regardless? Thanks for your insight in the matter.
            Andy

            • 3. Re: dealing with rollbacks and stuff

              > Peter,
              > what do you mean by handling messages? If one has
              > as a try/catch block in the onMessage() method and an
              > exception is thrown, does this mean the transaction
              > is rolled back or that some how the message is
              > requeued?

              If there is a EJBException thrown in onMessage, if you invoke setRollbackOnly or if any bean that is called from the MDB in any way has inherited the transaction (not of type NotSupported, RequiresNew and the like) causes a transaction rollback, then the message receipt will not be acked. The message will then (up to but not including JBoss 3.0) will be resent for ever until the bean finally handles the message or JBoss crash.

              > If this is indeed the case, would you recommend
              > nd BMP so that the MDB could commit the transaction
              > regardless?
              Yes, if the failing happend in another bean where transaction is autmatically rolled back. A guess another way of doing it is to require the called bean to start their own transactions.

              Hope this helps.

              //Peter

              > Thanks for your insight in the matter.
              > Andy