[rabbitmq-discuss] Fwd: question on the faq

[Gordon Sim]

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 
> interpretation 

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 
interpretation.

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 
> change.

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.