1 Reply Latest reply on Sep 30, 2008 12:17 PM by Adrian Brock

    Singleton MDB and FIFO on retry/rollback

    mparlee Newbie

      Hello,

      We have an application in which the order of incoming messages must be maintained. We have tried to achieve this behavior using a singleton MDB but have found that order is not maintained on rollback/retry.

      I've found a couple of threads that describe this as expected behavior and the following thread suggests it might be addressed in JBM 2.0. http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4103569#4103569

      Since we are currently on 4.0.5GA with JBossMQ I'm wondering if anyone has a suggestion or workaround that might enable us to guarantee ordered message delivery with our current singleton MDB approach.

      Thanks,
      Mike

        • 1. Re: Singleton MDB and FIFO on retry/rollback
          Adrian Brock Master

          It is virtually impossible for a JMS to guarantee this behaviour and still be efficient.

          The problem comes because a rollback/retry maybe initiated at some later date
          by the transaction manager for in-doubt transactions.

          The in-doubt transaction could be in an unfinished state because another branch
          of the XA transaction (e.g. database updates) may not be able to proceed
          through the commit stage (e.g. the database has crashed and needs recovering).

          This is not an issue unique to JBoss, e.g.
          http://www.devwebsphere.com/devwebsphere/2005/06/total_jms_messa.html
          which also identifies some of the other pitfalls which presumably you're less likely to
          make since they are more under your control. ;-)

          Having said that, it can be done and there a feature request for it:
          https://jira.jboss.org/jira/browse/JBMESSAGING-1151
          so you can vote for it.

          The main issue with this solution (don't deliver any other message
          to clients until you get an ACK from the one message that is allowed to be delivered)
          is that any in doubt XA transaction would have to be resolved
          in order to resume message delivery and there is increased latency
          for normal message delivery.

          If you want to implement it yourself then the MDB has to be aware of the order
          and NACK/rollback message deliveries that appear out of order.
          Again not very efficient, and not that easy to do across redeploys of the MDB
          without persisting the lastest order number somewhere.