[rabbitmq-discuss] Fwd: question on the faq
0x6e6562 at gmail.com
Tue Jan 6 18:33:31 GMT 2009
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
> 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?
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.
More information about the rabbitmq-discuss