[rabbitmq-discuss] Fwd: question on the faq

[Carl Trieloff]

Tim,

few comments in-line.

Tim Coote wrote:
> 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.

Just a note, we at the Qpid project interpret txn's to be atomic and 
support full XA and TM integration. So it works like any other messaging 
software that supports txn's

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


TX and DTX ARE to cover the 'normal semantics of a transaction'  The DTX 
work in AMQP was done by the guys that worked on Arjuna, Bluestone, 
Encina and a few other TMs. TX in 0-10 and 1.0 is just the 1PC case 
where you want transactional semantics with a single resource the 
broker, as where DTX is needed when you want more than one transactional 
resource. In AMQP 1.0 you will see that en-listing of txn has been moved 
to the session, and the coordinator part of DTX has been named such so 
avoid the TX/DTX confusion.

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

Ack, this is what TX and DTX are for

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

correct

> Using the AQMP definition, all I know is that the booking requests 
> were delivered, and possibly not even that they'd all been delivered.

AMQP transaction means that all the messages in the txn where correctly 
enqueded/dequeded on the broker or aborted atomically. i.e all my 
messages in the txn where consumed are put back in an abort atomically 
and all my published messaged are enqueued. Also that no published 
messages are made available to the consumer until the txn has been 
committed.

>
> tx and dtx classes have value (I still need to get to the bottom of what).

This is my key point -- if you chose to decide that the AMQP transaction 
is not atomic, I have no clue what it is used for and I no way in a 
transaction in my mind.

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

The content of the message is transactional as it is contained in the 
message.

Carl.