[rabbitmq-discuss] is anybody using tx?

[Alessandro Ranellucci]

On 28-06-2011 at 10:25, Matthias Radestock wrote:

  >How does the "check object status before processing" work? 
Couldn't a
  >consumer get the message(s) before the rdbms transaction has
  >committed, thus not see the up to date status and erroneously ignore
  >the message?

Message age is a good way to catch that. If it's too recent 
(10s? 30s?), I just reject it to have it redelivered few seconds 
later. When a message becomes too old and the database hasn't 
been updated with a correct status yet, I discard the message. 
Staff is notified then, to check why a RDBMS commit failed or 
why did it take more than 30 seconds.

Actually, by looking at my application logs, no messages were 
ever rejected because of early arrival, so it's a very edge case 
and I can live with the possible overhead of having a message 
delivered twice while the RDBMS commits its transaction.

  >> >Are you relying on tx atomicity at the moment? If so, can you
  >> >elaborate on the specific use case? Also is the "only 
atomic for a
  >> >single queue" restriction of AMQP's tx ok for your app?
  >>
  >>Hmm. Er... that limitation sounds new to me. Didn't pay 
attention :-)
  >
  >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?

Alessandro