[rabbitmq-discuss] Fwd: question on the faq

[Alexis Richardson]

Tim,

On Wed, Dec 31, 2008 at 12:17 PM, Tim Coote <tim+rabbitmq.com at coote.org> wrote:
> Hullo

Hi, and thanks for joining the list.


> A neophyte's question:
>
> The  faq includes 'is rabbitmq transactional?'
>
> The answer is 'yes' and then says that it has atomicity and durability
> guarantees. What about Isolation and consistency?

There are senses in which AMQP, and RabbitMQ, behaviour can be
described as ACID, following the wikipedia definition:
http://en.wikipedia.org/wiki/ACID

In AMQP 0-8, 0-9 and 0-9-1, we can talk about individual messages and
commands, and the TX class which groups them.  In AMQP 0-10 we can
talk about conversational ACIDity which allows us to define DTX (XA)
and the famed 'idempotent delivery' aka 'once and only once', because,
in effect, sequence numbers are first class.

Certainly, individual message delivery in RabbitMQ is ACID in that:

* What the FAQ says is good
* Trivially, individual operations are isolated
* RabbitMQ does not map a consistent state to an observable inconsistent state

I think the last point is key to answering your question :-)

Of course this says nothing about the TX class which groups operations
atomically, and respects durability in the intuitively correct way.
In this case isolation and consistency are significantly more
burdensome to guarantee.  As far as I am aware, but one of the
engineering team may wish to correct this:

* RabbitMQ guarantees weakly consistent states, i.e. once TX commits,
the state is consistent.
* For individual messages whose delivery is observable, it is not
possible to observe an inconsistent state after delivery
* Provided that the mandatory and immediate flags are not used,
isolation is guaranteed

This means that:

* for AMQP, if you use TX and avoid mandatory and immediate, you are 'good'
* also, for RabbitMQ, intermingling TX with mandatory and immediate
will lead to sensible behaviour, but I would prefer it if the
engineering team described what that means in practice.

A full treatment of consistency should be in AMQP 1.0.

The engineering team may wish to comment on the above - please take
with a dash of salt...



> (although the latter
> may be partly embedded in the apps that use rabbitmq,

Yes, as with DBMS, it may be cheaper to manage this at the app layer
in some cases.


> I think that
> consistency implies guarantees about serialisation/deserialisation).

Really?


> Is the answer buried in the semantics of a TX AMQP message type?

Yes - see above :-)


> I'd expect good engineering practice like ACID transactions and
> failfast guidelines in Erlang/OTP programming as I think that these
> are pretty much essential for any large scale system that's intended
> to be robust.  (Unlike many commercial programs ;-)

Yes, I think we follow good practice.  But do please note that
Erlang/OTP and AMQP are different beasts, and RabbitMQ tries to make
good use of the engineering in the former, to deliver minimally
confusing behaviour implementing the latter ;-)

Let us all know if this helps, and please ask more questions.

alexis




> Tim
>
>
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>