[rabbitmq-discuss] Fwd: question on the faq

[Ben Hood]

Tim,

On Tue, Jan 6, 2009 at 5:22 PM, Tim Coote <tim+rabbitmq.com at coote.org> wrote:
> These steps are all from the pov of my application.  I'm assuming that there
> must be messages in both directions. If this were paper based, step 4 would
> include opening the mail and reconciling booking confirmations against
> booking orders sent out in step 2, + separate steps to handle timeouts, etc,
> which I'd expect to be in the context of the 'transaction'.  I could write
> this as a series of async processes, but my experience of that type of
> design when given to programmers is that I get much more complexity than I
> need.
>
> Does that make sense?

The bit that is confusing me is the intention of the transaction
(which I guess is the crux of this whole thread :-)

So going back to you paper based analogy, what is the logical unit of work?

Is it

a) send out n requests and if any error occurs, 0 requests get sent
because they are grouped in a transaction;
b) send out n requests and wait for every result to come back and then
if there is an error with any response, roll the whole thing back

?

The reason why I ask is because I can't see how (b) can work unless
you propagate the transactional context to all of the consumers of the
requests. But as I said before, I'm probably missing the point.

Ben