[rabbitmq-discuss] is anybody using tx?

Mon Jun 27 21:47:58 BST 2011

On 27/06/2011 19:44, Gordon Sim wrote:
> On 06/27/2011 07:30 PM, Matthias Radestock wrote:
>> On 27/06/11 19:21, Gordon Sim wrote:
>>> On 06/27/2011 06:51 PM, Matthias Radestock wrote:
>>>> Also is the "only atomic for a single queue" restriction of AMQP's 
>>>> tx ok
>>>> for your app?
>>>
>>> Its not really fair to say that that is a limitation of AMQP.
>>
>> I am trying to ascertain to what degree people rely on (just) what is
>> guaranteed by the AMQP 0-9-1. Implementations are of course free to go
>> beyond that.
>
> Yes, but as you know the reason that the full atomicity guarantee was 
> not clarified in 0-9-1 was that RabbitMQ did not support it.
>
> I'm certainly not saying you should, either. It's entirely reasonable 
> to consider whether any additional feature is in fact used and needed.
>
> I just think its a little unfair to portray it as a question of 
> inadequate guarantees in the specification since that guarantee was in 
> fact limited by implementation.
Gordon,

Last time I looked I looked at MRG it was using separate journals for 
each queue and, in case of failure, couldn't guarantee atomic 
transactions with publishes or acks across multiple queues. This was 
common knowledge when I worked at Red Hat and something the MRG team, 
unsurprisingly, liked to keep quiet about. Customers tend not to be 
happy if they're told their transactions aren't really transactions.

Maybe you've fixed your implementation by now (although it's hard to see 
how you could do it without resorting to some slow, clunky, hand rolled 
2PC protocol), but please bear in mind that by pointing your finger at 
Rabbit, when you're own implementation was no different in that regard 
smacks of hypocrisy.