[rabbitmq-discuss] Fwd: question on the faq

[Tim Coote]

b) is the correct answer. That's what a transaction means - you cannot  
dip in and out of the transaction.

However, it is possible to have a compensating transaction, as part of  
the rollback - eg the downstream systems may not support enough state  
transitions, so a booking would imply a contract, which would have a  
cost to get out of.  This is the common approach for any systems that  
drive the physical world (eg producing printed material or driving a  
robot.)  Even in this type of scenario, the transactional model makes  
it easier to get the analysis complete and correct, although it's  
better to get the downstream systems to support suitable states.  eg,  
in the real world, I can make a provisional booking, which times out  
if I don't commit to a firm booking within a known (possibly variable)  
timeline.

I find that without this approach, the overall requirements/analysis  
and design is frequently incomplete, revealing inconsistencies between  
the assumptions of the upstream and downstream systems and costly  
remediation.

Tim


On 6 Jan 2009, at 18:33, Ben Hood wrote:

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

Tim Coote
tim at coote.org
vincit veritas