[rabbitmq-discuss] is anybody using tx?

[Matthias Radestock]

Alessandro,

thanks for elaborating on your design...

On 28/06/11 08:54, Alessandro Ranellucci wrote:
> If a filesystem write fails, I rollback both the RDBMS and RabbitMQ
> transactions. Then I send a tx.commit to RabbitMQ; if this fails I
> rollback the RDBMS. Finally, I commit the RDBMS.
>
> My message consumers are idempotent and always check object status in
> RDBMS before processing messages, so should I fail to commit to RDBMS
> after having committed to RabbitMQ, those messages will be ignored.

Idempotence is certainly a good thing.

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?

>  >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?

I doubt many people are aware of the that limitation. In fact in 
RabbitMQ not even single queue transactions are atomic, i.e. in the 
event of a failure during the commit phase you may end up with a sub-set 
of the published messages in the queue. It's highly unlikely, but 
certainly possible.


Regards,

Matthias