[rabbitmq-discuss] atomic transactions
jonathan.gaillard at dominionenterprises.com
Fri Mar 23 14:25:37 GMT 2012
Emile Joubert <emile at ...> writes:
> On 22/03/12 03:39, gaillard wrote:
> > I have need to use transactions in the following way:
> > -get a message (m1) from queue A
> > -transforms the message and create new message (m2)
> > -publish m2 to queue B
> > -ack m1
> > -commit the transaction (includes ack and publish)
> > Which i believe in all failure scenarios should result in possibly two
> > things:
> > m1 on queue A, nothing on queue B
> > m2 on queue B, nothing on queue A
> > Is this what will happen in rabbit 2.7 or 2.8?
> Mostly yes, but bear in mind that transactions are not atomic in
> RabbitMQ. So if the broker crashes or an error occurs during commit then
> your invariant might not hold. If you are dealing with very high value
> messages then you should add additional logging and correlate the input
> and output.
> This page has more information about transaction semantics:
Well i have done some testing with different failure cases now..
As far as I can tell if the broker stays up, and clients are the ones that fail,
the transactions are adhered to atomically. But if I kill the broker its not
hard to get messages where they shouldnt be.
I dont have need for persistent messages so I think i am safe with relying on
the atomicity since on broker death the messages are gone anyways. Is this not
Any idea when fully atomic transactions will be put in rabbit? It is a common
feature on jms and qpid etc..
Also, would you mind elaborating on how you would correlate in the publishing
back to the same queue where you dont want multiple copies on that queue? The
best I can come up with is just erroring if you receive the redelivered. But
redeliveries are ok with the transaction route since you will never get the
multiple copies. I see no substitute for transactions.
Thanks for the help !
More information about the rabbitmq-discuss