[rabbitmq-discuss] Fwd: question on the faq
cctrieloff at redhat.com
Mon Jan 5 16:12:05 GMT 2009
Matthias Radestock wrote:
> 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.
that is ridiculous. I don't know of any transaction impl that is not
ACID, if it is not ACID what is the point? Differentiating between 1PC
(local) and 2PC is meaningful, but both are ACID, that is the point on a
transaction. If the txn is not ACID, why not just acknowledge the
message, there is to difference in the failure cases between a non ACID
txn and an ack then.
More information about the rabbitmq-discuss