[rabbitmq-discuss] is anybody using tx?
aar at cpan.org
Tue Jun 28 21:13:45 BST 2011
On 28-06-2011 at 10:25, Matthias Radestock wrote:
>How does the "check object status before processing" work?
>consumer get the message(s) before the rdbms transaction has
>committed, thus not see the up to date status and erroneously ignore
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
>So in your app, can the messages inside a tx can end up in multiple
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?
More information about the rabbitmq-discuss