[rabbitmq-discuss] Fwd: question on the faq
gsim at redhat.com
Mon Jan 5 13:57:29 GMT 2009
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).
More information about the rabbitmq-discuss