Announcement Announcement Module
No announcement yet.
Spring AMQP Transaction Management Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring AMQP Transaction Management


    I'm looking for some information on Spring AMQP and transaction management.
    Does Spring AMQP allow things like messaging transactions that get coordinated by an application server transaction manager or Spring transaction manager, like JMS does?

    Apparently RabbitMQ does not support this yet but it's in the pipeline (see

    Note: as remarked in the comments on the blog entry: indeed, in general I would try to avoid XA, but there are situations where exactly-once semantics are important.


  • #2

    Our plan for transaction support in AMQP is to mirror Spring's approach in JMS as closely as possible. That means we do plan to provide an AmqpTransactionManager analagous to the JmsTransactionManager (it's not yet in the M1 release as you may have noticed), but that typical "local" transactions can be managed without that (e.g. directly at the publisher's send, ... receive transactions in AMQP are a bit different than in JMS, but that's another story). As far as JTA support, we would add it once the AMQP dtx is supported even though we would typically recommend avoiding global/distributed transactions (favoring the non-JTA options that Dave Syer describes in this article:



    • #3
      Can you provide an simple example of how to do local transactions in Spring AMQP ?


      • #4
        Originally posted by geoffma View Post
        Can you provide an simple example of how to do local transactions in Spring AMQP ?
        I am looking at this problem now. essentially i have a spring amqp inbound adapter that reads messages from a queue. Down stream the program does some header enrichment, and then 2 SQL insert statements via JDBC out bound gateways and it ends up the message goes back to an outbound amqp adapter to another queue. SO how would I put transaction support so that if any of the JDBC operations fail, all the operations and the message remains on the original queue?


        • #5
          In general, it's better to start a new Thread than revive a nearly 3 year old one (you can reference the old one if necessary).

          Bear in mind that Rabbit does not have XA transaction support so the "Best Effort 1PC" pattern described here is the best that can be achieved.

          Spring implements this pattern for you by deferring the commit of the JDBC resources until immediately before committing the Rabbit transaction. So, as long as all your upstream JDBC activities are performed on the container thread, the Rabbit transaction will only be committed if the JDBC transaction is committed; if there's a failure, the message will be nacked and redelivered to this, or a competing, consumer.

          Simply provide the inbound adapter with a reference to the JDBC transaction manager and Spring will synchronize the transactions.