[rabbitmq-discuss] is anybody using tx?

[Matthias Radestock]

Alessandro,

On 28/06/11 21:13, Alessandro Ranellucci wrote:
> On 28-06-2011 at 10:25, Matthias Radestock wrote:
>  >So in your app, can the messages inside a tx can end up in multiple
>  >queues?
>
> Yes, and I think it could be a common case. For example, a transaction
> in my system may contain:
> - a message to "deliver.product.to.customer";
> - a message to "charge.prepaid.account";
> - a message to "notify.customer.by.sms".
>
> How could I handle that without AMQP transactions?

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 (though, as Gordon pointed out, 
implementations are free to extend that to multiple queues, which would 
then be sufficient to do the above).

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. But then 
again message duplication is quite prevalent in messaging systems, so an 
app will likely have to deal with that anyway.

This technique is of course is not a direct replacements for 
fully-fledged transactions, but it works remarkably well in many situations.

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?


Regards,

Matthias.