[rabbitmq-discuss] Fwd: question on the faq
tim+rabbitmq.com at coote.org
Mon Jan 5 15:11:09 GMT 2009
Remember, I'm new to messaging technology. I'm coming at this area
from a more general perspective. Starting with Gray and Reuter's
definition of a Transaction (an ACID unit of work). My guess is that
the term's used in a different way in the messaging community, so I'm
likely to make mistakes. My background is mostly about understanding
how to control technology and its use, so I focus on understanding the
Atomic means either everything happens or nothing happens as far as
the system using a transactional interface is concerned. At minimum,
I'd expect that if my app sends a message to n recipients, they either
all get it or none of them do and my app is reliably informed what the
outcome was. I interpreted Gordon's comment to mean that there were
side effects that could be abused by programmers to mean that the
message had got through. My concern would be that some programmer
would use a side effect and come to the wrong conclusion. I probably
need to read the specs before I make more of a fool of myself. I'll
try to read them before I make any comment after this.
From your bottom example, I'd say that if one of the queues
disappeared before the tx had been committed, then it should fail and
rollback. It sounds like a 'theoretically' simple example in
distributed systems :-) There seems to be a bigger problem in
assuring consistent arrival of messages at a destination in a unicast
case, let alone a multicast model.
I know some of the guys in JPMC at that time. They knew what they
were doing. Of course, they could have been different people from the
ones that were working on what became RabbitMQ, although one did tell
me that he was sponsoring some open source messaging work.
On 5 Jan 2009, at 12:55, Alexis Richardson wrote:
> 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
> 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
> 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.
>> 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
>>>>> A neophyte's question:
>>>>> The faq includes 'is rabbitmq transactional?'
>>>>> The answer is 'yes' and then says that it has atomicity and
>>>>> guarantees. What about Isolation and consistency?
>>>> There are senses in which AMQP, and RabbitMQ, behaviour can be
>>>> described as ACID, following the wikipedia definition:
>>> 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
tim at coote.org
More information about the rabbitmq-discuss