[rabbitmq-discuss] is anybody using tx?

Wed Jun 29 20:08:15 BST 2011

Matthias,

On 28-06-2011 at 22:41, Matthias Radestock wrote:
  >Well, you cannot actually handle that directly *with* an AMQP
  >transaction *as defined in the spec*, since they guarantee atomicity
  >for single-queue transactions only

you're right. I paid poor attention to that limitation.

  >One way to handle this scenario in RabbitMQ is to put the 
channel in
  >'confirm' mode, send all three messages and wait for the
  >confirmations. If there is a failure then re-send the 
messages that
  >didn't get confirmed. That may result in duplicate messages 
(e.g. if a
  >confirmation was lost due to a connection failure), so you'd 
need to
  >make the messages idempotent / do dup detection at the 
consumer end.

What if I'm not able to resend the messages that didn't get 
confirmed? Say, RabbitMQ stops working after I got confirmation 
of only two messages out of three. What should my application 
do? What response should I return to my external process? I 
can't return success because RabbitMQ only accepted some of the 
messages, and I can't even return a temporary error because some 
messages were actually accepted. Should I return "partial 
success" and implement a local queue to retry messages to 
RabbitMQ? :-)

  >Looking at your example though makes me wonder why an app 
would want
  >these messages to be delivered atomically anyway. Surely one would
  >want to charge the prepaid account first, then, *if that succeeds*,
  >deliver the product, then *if that succeeds*, notify the 
customer. No?

That's the case if your operations are blocking each other and 
can return success or failure. However, many designs involve 
asynchronous operations which can't fail and have no impact on others.

Say that you had already reserved some credit: you only need to 
settle that reservation. There's no hurry to do that, and no 
chance for it to fail. At worse, your billing database could be 
temporarily unavailable, but there's no reason to block product 
delivery. You might support less concurrency, or put less 
resources, on your billing database than you do for product 
delivery. Otherwise, if I chain all components in my workflow, I 
will put a lot of bottlenecks and make everything critical.

Cheers,

Alessandro