[rabbitmq-discuss] Fwd: question on the faq
matthias at lshift.net
Mon Jan 5 15:42:39 GMT 2009
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
All the above is true of RabbitMQ. But we do not guarantee atomicity in
the event of tx *failure*.
More information about the rabbitmq-discuss