[rabbitmq-discuss] Fwd: question on the faq

[Dmitriy Samovskiy]

Hi Tim,


Tim Coote wrote:

> 
> 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
Well, if all items you mentioned above are booked via the same processor engine, I would 
say you send 1 aggregate booking message and receive 1 aggregate confirmation message, and 
transactionality in this case is handled by consumer (processor engine) in its code, not 
in AMQP.

If all items are booked via different engines, wouldn't you want to keep track of your 
transaction on producer (booking client), also not in AMQP?
Book cab - receive confirmation
Book insurance - receive confirmation
Book flight - oops, sold out
Cancel insurance - receive cancel confirmation
Cancel cab - receive cancel confirmation
return fail

I do understand that a failure in the middle of cancellations (say between cancel 
insurance and cancel cab) would be tricky, but you can retry. Or - maybe even better - you 
can "return fail" right after "oops, sold out" and go through cancellations asynchronously 
  behind the scenes?

In your example, it kind of looks to me like you expect broker somehow to know that in 
response to your published messages (sent in a transaction) there will be some number of 
response messages (not necessarily 1-to-1 - what if airline reservation comes in several 
msgs?) coming from some sources which broker must somehow know to include in the same 
transaction. How will you communicate this requirement to the broker? Wouldn't keeping 
this logic in client (with integration to business rules, etc) be better?


Please note this thread is way out of my league though, so please feel free to ignore this 
message :)

- Dmitriy