[rabbitmq-discuss] Fwd: question on the faq

[Tim Coote]

Hullo
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  
limits first.

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.

Tim


On 5 Jan 2009, at 12:55, Alexis Richardson wrote:

>
> 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
>>
>

Tim Coote
tim at coote.org
vincit veritas