[rabbitmq-discuss] atomic transactions

[gaillard]

Emile Joubert <emile at ...> writes:

> 
> Hi,
> 
> 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:
> http://www.rabbitmq.com/semantics.html
> 
> -Emile
> 
> 

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

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 !