[rabbitmq-discuss] Fwd: question on the faq

[Tim Coote]

I'm getting the sense that as far as AMQP is concerned, the word  
Transaction is not helpful as it sort of implies similar semantics to  
the work on ACID semantics for programming models (TP monitors, DBMS,  
SQL, X/Open's XA, etc), which are concerned with the properties of the  
control of the operation (which seems to be what AMQP is mostly  
concerned about) AND the guarantees on the contents of the operation,  
which seems to me to be considered out of scope for AMQP - that's why  
XA talks about Resource Managers: it's concerned about the integrity  
and correct state transitions of resources that are managed.  I can  
see a strong revenue stream in explaining to clients that their  
proposed application architecture is broken because they've assumed  
that Transaction in AMQP is comparable to their understanding from  
using TP monitors, or even just API guarantees.

I can see value in what I think AMQP is trying to achieve (based on a  
cursory skimming of the 10 spec and this discussion), but it needs to  
be clear to the app architects that they will need to layer on top of  
the protocol a whole extra chunk of app to do the reconciliation of  
state between the systems, which can largely be avoided with  
(traditional) transactional systems.

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.

tx and dtx classes have value (I still need to get to the bottom of  
what). However, their naming - especially if dtx is defined in terms  
of XA spec, but doesn't cover the content of messages, is going to  
create an adoption barrier to the technology.  Have a scan of XA and  
DTP and see if you agree.  (Section 2.2 et seq - I won't reproduce it  
here: it's short, but doesn't format well when I drop it into an email).

Anyway, that's my three ha'porth.

Tim

On 5 Jan 2009, at 16:57, Carl Trieloff wrote:

>
> Tim Coote wrote:
>> I've now read a bit of the specs :-)
>> amqp defines tx classes (which are not transactional in the sense  
>> of  XOpen's XA specification) and dtx, which are.  I don't  
>> understand, at  the moment, what tx really means in the context of  
>> a message passing  system, but I suspect that it's something to do  
>> with some sort of  'transactional' model with a message server (or  
>> whatever I call the  agent that my application interacts with that  
>> is its interface to the  messaging system): I can send messages to  
>> the message server with  transactional semantics, but there's no  
>> downstream semantics. I'm not  very clear on how this is a useful  
>> piece of functionality as I cannot  see what guarantees I get for it.
>>
>> iirc, MQSeries had similar semantics about 'guaranteed delivery',   
>> which are not much use, either, as you still have to put in place   
>> checks for message receipt by the end point.
>
> you comment on 'guaranteed delivery'  is spot on. tx in msg system  
> allows you
> to ACID commit or rollback  1-N msg onto 1-N queues. or consume 1-N  
> messages
> from 1-N queues and either commit or rollback the full set in the  
> TXN in a ACID
> fashion.
>
> AMQP
> TX == 1PC for local transactions, not coordinated by a TM
> DTX == 2PC and can be coordinated by a TM (optionally XA) if desired.
>
> Carl.
>

Tim Coote
tim at coote.org
vincit veritas