[rabbitmq-discuss] Fwd: question on the faq

Mon Jan 5 12:55:14 GMT 2009

Tim,

On Mon, Jan 5, 2009 at 12:36 PM, Tim Coote <tim+rabbitmq.com at coote.org> wrote:
>  Mostly the value comes from
> not having application programmers try to fix errors that they
> misunderstand, leading to increased cost and decreased quality and
> performance.

I agree this is a key benefit of ACID in a system with side effects.
But it is also important to be clear about what sorts of consistency
(etc) are promised.

> your description implies to me that RabbitMQ message delivery cannot
> be Atomic, even at the single message level,

I don't understand how you can draw this conclusion from what I said
(note that the comment below is from Gordon).

My statement included the assertion that at the single message level
RabbitMQ delivery *is* atomic.  Without single message atomicity it
would be very hard to reason about consistency *at all*.

> let alone defining units
> of work that span messages.

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.

We would welcome a discussion of the subtleties of TX on this list.
If you can find holes in our implementation we would be delighted to
make it better!

> Shame.  Promising that it's even been discussed tho'.

TX was defined in the period 2004-2006 before AMQP became a public
spec, when it was in incubation at JPMorgan Chase with the assistance
of several groups of software professionals.  But it's not yet
perfect.

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'll see if I
> can find the spec that you refer to.

Please do take a look and let us know what you think.

Cheers

alexis

>
> Tim
>
> On 5 Jan 2009, at 11:35, Gordon Sim wrote:
>
>>
>> Alexis Richardson wrote:
>>> On Wed, Dec 31, 2008 at 12:17 PM, Tim Coote <tim+rabbitmq.com at coote.org
>>> > wrote:
>>>> 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 recent discussions on improving the text for the tx 'class' in
>> the 0-9-1 spec there appeared to be some disagreement around the
>> atomicity guarantee.
>>
>> In particular, I understood from comments by members of the RabbitMQ
>> team that though effects of all contained (publish and ack)
>> operations are visible if the the commit is successful, RabbitMQ
>> does not guarantee that none of them would be visible in the event
>> of a failure.
>>
>
> Tim Coote
>
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>