[rabbitmq-discuss] Fwd: question on the faq

[Matthias Radestock]

Carl Trieloff wrote:
>> Not quite. Firstly, if queues are active entities, which they are in 
>> RabbitMQ, then they can, in principle, die due to some failure. 
>> Secondly, in a clustered RabbitMQ broker each queue resides on a 
>> specific node. In such a set up a transaction may take place on a 
>> connection+channel against one particular node but involve queues 
>> residing on other nodes. Those queue can disappear due to node failure 
>> or network connectivity disruption without the transacted 
>> connection+channel being dropped (since the node which holds the 
>> connection is still alive and well).
> 
> Sound like a bug. 

Huh? None of the the above actually preclude an implementation of ACID 
transactions; I am simply explaining why it's not quite as simple as 
people might think.

> If something is transactional then it should be ACID

Only if the spec says that it should be, which it doesn't.

> so if a node fails and is restarted it
> should be recover-ed from the transaction log. Once a client has 
> successfully committed
> the txn, the broker weather single instance or cluster should be in a 
> consistent state
> or be able to be recover-ed to the consistent state to trans-send the 
> failure.

All the above is true of RabbitMQ. But we do not guarantee atomicity in 
the event of tx *failure*.


Matthias.