[rabbitmq-discuss] Fwd: question on the faq
gsim at redhat.com
Mon Jan 5 20:51:09 GMT 2009
Matthias Radestock wrote:
> Alexis Richardson wrote:
>> In fact one can take two different views of transactions in the sense
>> of AMQP TX:
>> 1. Operations are operations on *resources* - so more like databases
>> (Jim Gray et al.).
>> 2. Operations are about control of a *stream*.
> I reckon this distinction is at the heart of some of the confusion on
> this issue.
> RabbitMQ is firmly in the second camp. And it *is* ACID under that
I'm not sure I follow you. If, as I understood your earlier comment to
imply, the various transactional operations cannot be atomically
aborted, it would seem to me that it is not ACID under either
E.g. if a transaction where I publish a message and acknowledge another
is aborted, is it possible that the published message is delivered to a
subscriber of some matching queue and the acknowledged message is left
on the queue and is subsequently redelivered to another subscriber? If
so it is not atomic.
Personally I'm not convinced the stream/resource distinction alters the
issue which for me relates to the success of operations. A successful
publish operation causes a message to become available for delivery to
subscribers on all matching queues; a successful ack operation prevents
the referenced message from being redelivered. Atomicity means that
either all the are 'successful', or none of them have any effect.
> And because ...
>> Routing to a queue is acceptable streaming behaviour. So
>> if the queue fails after being routed to, then it is not unreasonable
>> to treat something as having 'happened'.
A bug (or indeed some hardware failure) may prevent a message from being
accepted by the queue. Thats a different case from the queue not
existing. In the current AMQP routing model publishing a message for
which no binding matches is not an error, but the failure or a bound
queue to accept a message routed to it is in my view an error and should
be signaled as such.
> ... arguably, to be fully consistent with the second interpretation a
> tx.commit (and rollback) should *succeed* even if some of the queues to
> which messages/acks were delivered disappears. RabbitMQ's tx.commit
> currently returns an error for this, which is something we may want to
If the queue is explicitly deleted by the application, I think thats
fair enough. If it 'disappears' due to some failure condition I think
that should cause an error which would in turn abort the transaction.
More information about the rabbitmq-discuss