> An example of this going wrong in production, I work in the online gaming (gambling) industry. One of our users won a large jackpot, our code started a transa

> An example of this going wrong in production, I work in the online gaming (gambling) industry. One of our users won a large jackpot, our code started a transaction, contacted the 3rd party to have them release the funds, recorded the win in the transaction journal, updated the customers balance etc. Then the stored procedure which inserted a row into the outgoing email queue had a small error. This caused all of the database work on our end to rollback. Updating a customer's winnings and recording a win are definitely things that should be together in a transaction - if one happened and not the other, that's a failure. This is not the fault of using a transaction, this is the fault of not working with what is essentially a distributed transaction. Since you are relying on a message against a third party, you need to build distribution into this system, which is challenging. You might contact the third party after you've completed the internal processing, and you might use two-phase semantics even such that you can "PREPARE TRANSACTION" the work you've done locally, (nearly) guaranteeing that a commit will proceed, then work with your external messaging, then commit locally. background at http://en.wikipedia.org/wiki/Two-phase_commit_protocol http://en.wikipedia.org/wiki/Two-phase_commit_protocol