[rabbitmq-discuss] Fwd: question on the faq

[Gordon Sim]

Alexis Richardson wrote:
> RabbitMQ provides a correct implementation of the TX class which
> enables work to be grouped.  It is the TX class to which Gordon refers
> in his email below.  The problem is that the definition of TX is open
> to *some* interpretation in edge cases, and is implemented slightly
> differently by the various brokers.  When we discussed the differences
> in the working group we agreed that it would be more useful to clarify
> how each 'correct' interpretation actually works for pre 1.0 specs,
> pending AMQP 1.0.

I referred to comments made about the atomicity guarantee in the 
RabbitMQ during discussions on clarifying the text of the TX class.

My view has always been that the TX class implied atomicity (and the 
original author confirmed that was his intention), but the text of the 
0-9 (and earlier) spec(s) did not make that explicit.

Members of the RabbitMQ team were not keen on making it explicit when 
the 0-9-1 corrections were published. As I understood their comments, 
this was because RabbitMQ had not assumed 'all or nothing' semantics. 
(And I accept that given the original wording, that is a perfectly valid 
interpretation of the text).

> The complexity of TX arises due to the fact that messaging is about
> routing and delivery as much as it is about enforcing various forms of
> seriality in the presence of change.  For example consider the case
> where N messages are sent in a TX transaction, over multiple queues,
> and during this operation one queue disappears (eg due to failure).  A
> proper treatment of this requires a proper treatment of multiple
> failure cases, and a clear definition of ordering.

I agree that the behaviour of transactional operations (and indeed 
several non-transactional use cases) when queues are concurrently 
deleted or bindings are concurrently changed is important to define.

A general atomicity guarantee is more basic than that though and would 
in my view be valuable even if it only applied where queues involved in 
that transaction were not deleted during the life of the transaction.

(Note the only way a queue should disappear due to failure is if the 
broker restarts and the queue was not durable, in which case any open 
transactions would be aborted).