[rabbitmq-discuss] Fwd: question on the faq

Tue Jan 6 12:37:48 GMT 2009

On 6 Jan 2009, at 11:51, Alexis Richardson wrote:

>
> Tim, many thanks.
>
> Also, Gordon and Carl, thanks for your thoughts which really helped by
> forcing us to clarify stuff.
Good.
>
>
> I am going to re-paste Matthias' last comment which is relevant:
> "Finally, it's worth reiterating that RabbitMQ *does* guarantee
> atomicity in the cases required by the 0-9-1 spec, namely "where all
> publish or ack requests affect a single queue.""
I'm sure that RabbitMQ implements the spec. I come more from the angle  
of getting the spec right. I want my customers to be able to avoid any  
product lock-in.
>
>
>
> On Tue, Jan 6, 2009 at 10:42 AM, Tim Coote <tim 
> +rabbitmq.com at coote.org> wrote:
>> I'm getting the sense that as far as AMQP is concerned, the word
>> Transaction is not helpful
>
> I must admit that I tend to share this view.  However, it is also
> clear from people's comments, notably Gordon and Carl, that other
> views are defensible.  In other words - this is all good fuel for
> making a better 1.0 spec.  In AMQP 1.0 we anticipate a much more
> rigorous definition of transactionality and 'resource' including DTX
> and idempotency.  Implementations supporting that will also have finer
> grained means for coping with TX anomalies such as corner 'failure
> cases'.
I'd recommend using a different term, eg 'transactional control', or  
(from my pov) inventing an entirely new word/phrase so that customers  
are aware that they need to look into what the phrase means.

[snip]
>
> And AMQP needs to play nicely with JMS which has its own
> resource-centric behaviours.
>
> TX for example can be related to the concept of a JMS local
> transaction (unless I have misunderstood this).  Moving data from one
> queue to another, on one broker, is not dissimilar to the TX use that
> Gordon described.
unsure. it's quite possible that the AMQP terminology started in the  
JMS world. iirc, the j2ee OTS service is the relevant transactional  
service. I don't know how the language and computational models  
percolated into JMS.
>
[snip]
> Of course the MAIN aim of AMQP is to simplify integration (and lower
> cost) by simplifying cross-platform messaging.  So it has to be
> cognitively obvious as well as semantically so.  Thanks for making us
> talk through this in the TX case.

It seems to make a good job of this, from what I can see.
>
>
> Please could you elaborate on the 'reconciliation of state'  
> requirement?
Whenever there is distributed persistence, there's a risk of the  
different views of the world getting out of sync. So you need some  
periodic checks that the views are consistent. If you have ACID  
semantics on the information, this happens infrequently and can be at  
quite a high level (eg testing that the history of the past or future  
plans have consistent totals for, say, number of bookings, or volume  
of material to be exchanged.)  If I have no ACID transactions, I ought  
to validate the result of each update/request for resources from each  
service explicitly. As I've got no distinct time boundaries around  
when the (application level) transaction completed, I need to build  
that functionality, too. This balloons the application design, build,  
and maintenance costs.
>
>
>> Using what I'd call the normal semantics of a transaction, I'd define
>> a unit of work that booked all of my components of my holiday in one
>> block and I'd know whether everything were ok or not. It also makes  
>> it
>> very obvious that I need to think about the legal contracts that I'm
>> 'committing' to so that I can form suitable compensating  
>> transactions.
>> Using the AQMP definition, all I know is that the booking requests
>> were delivered, and possibly not even that they'd all been delivered.
>
> Right and here one stumbles across the difference between TX, DTX and
> idempotent delivery.  But - correct me if I am wrong - wouldn't
> Gordon's use case help with this?
I'm not sure. I didn't get the gory details. But I don't think that it  
addresses the issue as I think it's concerned with the control  
mechanisms, not the content.  The point about my example is that I  
have guarantees on the ACID characteristics of the components of the  
holiday: not just that the booking forms were delivered to the  
companies concerned, but that they were accepted and correctly  
processed. By extension, I suppose that this could form the basis of a  
legal contract, but I'm no lawyer.

btw, an idempotent operation to me means that I can apply it one or  
many times and I get the same result (eg x=3, vs x+=1). Is this  
another 'broadened' definition :-)
>
>>
> Possibly so..  Do you use XA a lot then?
Yes. But as a reference specification/basis for application  
architectures/enterprise standards. Or as a pointer on how things  
should have been done on a post mortem ;-)  I do less of this type of  
work these days, but was heavily involved last century. :-)
>