In the bigger picture, this post asks the question “when do I know my business process is dead”? The points you raise are around “what do I do when my process is dead”? The key issue I wanted to raise is that many people prematurely kill their process using timeouts, when it may not be dead in the first place.

Once you kill a process then, yes you need to clean up. Distributed transactions (a la two-phase commit) is one textbook option, but I have never seen it work in practice for anything resembling a “business process”. Compensation is the more common approach.

This is good fodder for another post I think.

Any comments on a few other dimensions to this: namely transactions, retries and compensation.

End to End transactions are very rare, although you do see some point to point ones. This effectively makes retries completely redundant (although everyone still seems to put them in for some reason).

Compensation seems to be the dominant approach in the organisations I’ve seen, although it’s often poorly implemented – and often manual. Done well it can be quite effective, however.

Compensation can be better where a synchronous user-time response is absolutely mandatory. i.e. you can’t respond to the user asynchronously, as per Option 4.

However, it’s not necessarily the best for BPM. A compensating service effectively adds another scenario, which increases the complexity of the process. Generally speaking the process is better at determining what should/shouldn’t be rolled back for a particular case…

Jon

“Message Queue purpose in a webapp: Move operations out of the synchronous request cycle. Amortize load over time”