[rabbitmq-discuss] Fwd: question on the faq

[Tim Coote]

Thanks, Carl. Where can I find 1.0 - I could only find 10 when I  
looked at the amqp site.

Now I'm very confused. In my mind, to book my holiday example, I need:
1/ Begin transaction
2/ prepare definition of what to book (cab to airport, insurance,  
flight, hotel, etc)
3/ send booking requests
4/ receive and record booking confirmations
5/ Commit

with corresponding compensating transactions if any of the elements  
fails.

As far as I can see, 3 and 4 are dependent on the semantics of the  
message and how they are processed downstream, not just the queue that  
I'm sending them to/receiving them from. As a system specifier, I'd  
want to treat a booking failure for whatever reason (message didn't  
get thro' or no resource available) in the same way. I want all 5  
steps with ACID semantics (although I may swap 1 and 2 around). Have I  
got hold of the wrong end of the stick?

2pc vs 1pc is really just an implementation issue, it's much better if  
I can treat them as the same thing, at least initially, and fwiw, 2pc  
doesn't actually guarantee ACID semantics, although the hole is  
usually ignored and handled as a system failure.

On 6 Jan 2009, at 13:36, Carl Trieloff wrote:

>
>
> 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
Maybe I just need to be aware that the word Transaction means  
something different for messaging systems to elsewhere. If so, I bet  
working with Oracle (as a company) is a bunch of fun, as they mostly  
don't appreciate that a transaction doesn't imply a dbms :-)
>
>
> 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.
so the tx class is only to do with interactions with the messaging  
system itself (cf recorded delivery for the postal service), vs a  
simple order processing model (send order, schedule delivery, confirm  
order).
>
>
>> 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.
Surely the luw would normally include correct consumption and  
processing of the messages, otherwise all that my app knows about the  
state of the world is that the messages went. I was coming to the  
conclusion that that was the AMQP guarantee (essentially proof of  
sending or proof of delivery), but your example implies to me that it  
could also include correct understanding of, and action on the messages.
>
>
>>
>> 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.
if and only if the luw is the sending/receipt of the message, which is  
ok, but I don't think it's what you're saying.
Tim