[rabbitmq-discuss] Fwd: question on the faq

[Gordon Sim]

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 
lifecycle undefined.

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.