[rabbitmq-discuss] Fwd: question on the faq
gsim at redhat.com
Mon Jan 5 17:20:49 GMT 2009
Alexis Richardson wrote:
> During the 0-9-1 discussions the group came to the realisation that
> either (a) TX qua 0-8/9 was more naturally seen as a generalised
> acknowledgeable group of work,
I very much disagree that the 'group' came to any such realisation.
> or (b) that the semantics of TX needed
> to be amended. Such semantic amendments were of course out of scope
> for 0-9-1, *and* with 1.0 'in view' for 2009, *and* absent a full
> account of failure in 0-8/9, the former view (a) prevailed. So 0-9-1
> has its own view of what a TX transaction is.
Again, my view is somewhat different. I think the text describing the tx
semantics in 0-9 was generally viewed as inadequate (and in my
particular view also confusing).
Addressing all corner cases (e.g. interactions with immediate and
mandatory flags) was felt to be out of the scope of the 0-9-1 corrections.
A clarification to the text was proposed that happened to make the
atomicity guarantee explicit. This wasn't meant to be a change, merely a
clarification. However, since the RabbitMQ teams interpretation of the
specification (and again I'll be clear that it was a legitimate
intepretation given only the text in the spec) would have been
invalidated by such a change, it was again felt to be out of scope.
There was never any agreement that a tx transaction was *not* atomic,
only a failure to agree that it was which resulted in the text being
left unchanged in that regard.
> More generally, it is dangerous to assume that a messaging system not
> subject to full XA type constraints is like a database in every way.
> In 0-8/9 AMQP, TX can only guarantee atomicity in the presence of
> failures if every broker operation is a transaction in the same sense
> as in a database. So for example in 0-8/9, individual message
> delivery is *transactional* and *atomic*, but queue failure is not
> guaranteed to be so because the queue lifecycle is simply *undefined*
> in 0-8/9.
I don't agree the queue lifecycle is undefined in 0-9 (though perhaps I
misunderstand what you mean there): it starts with the first
queue-declare and ends with a queue-delete. Auto-deleted queues
certainly complicate that slightly, but not so far as to make the
While I agree that clarifying the expected behaviour when a queue
involved in a transaction is deleted before the transaction commits
would be valuable (i.e. are the relevant ops simply ignored, or does the
deleted queue force the transaction to be aborted), I don't agree that
the tx class could not quite simply include a statement on the atomicity
without that however.
More information about the rabbitmq-discuss