[rabbitmq-discuss] Fwd: question on the faq
tim+rabbitmq.com at coote.org
Tue Jan 6 10:42:26 GMT 2009
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.
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
> from 1-N queues and either commit or rollback the full set in the
> TXN in a ACID
> TX == 1PC for local transactions, not coordinated by a TM
> DTX == 2PC and can be coordinated by a TM (optionally XA) if desired.
tim at coote.org
More information about the rabbitmq-discuss