3 Replies Latest reply on Feb 10, 2004 8:43 AM by spohl

    MDB UserTransaction

    s_thom Newbie

      This is probably a more general question:-

      In the EJB2.0 spec it says that an MDB that specifies REQUIRED for a container managed transaction ensures that the dequeue of the JMS message must enlist with the same transaction context as the onMessage. Therefore if the onMessage sets RollbackOnly eveything the onMessage did is rolled back along with the JMS message - causing a JMS retry.

      But, what happens if you specify a Bean managed transaction? By the time onMessage is called the message has already be dequeued by the container so when you call begin() on the user transaction the JMS message cannot be part of this transaction. I think this is correct? But, has JBoss already started its own transaction for the dequeue? If so how does this work with the UserTransaction - or am I talking a load of rubbish?

      Anyone got any ideas?


        • 1. Re: MDB UserTransaction
          Adrian Brock Master

          The JMS tranaction is suspended before it invokes
          your BMT MDB.


          • 2. Re: MDB UserTransaction
            s_thom Newbie

            If that is the case then how do I cause the container to rollback in an exception situation? I can obviously rollback anything I do inside the onMessage but I will be unable to force JBoss to retry the message.

            • 3. Re: MDB UserTransaction
              spohl Newbie

              That would be interesting for me too. How can the suspended Container transaction (that dequeued the message) be hinted NOT to acknowledge the receipt so that it will be resend?

              In 15.4.13 the EJB spec 2.1 says expressly: "If a message-driven bean uses bean-managed transaction demarcation and throws a RuntimeException, the Container should not acknowledge the message."

              Something for the todo list for J2EE compliance? :-)