[rabbitmq-discuss] Fwd: question on the faq

Tue Jan 6 11:51:00 GMT 2009

Tim, many thanks.

Also, Gordon and Carl, thanks for your thoughts which really helped by
forcing us to clarify stuff.

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

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

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

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.

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

OK ;-)

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

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.

Please could you elaborate on the 'reconciliation of state' requirement?

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

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

Possibly so..  Do you use XA a lot then?

> Anyway, that's my three ha'porth.

Thanks!

alexis

> 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
>
>
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>