Can I rely on the MSDTC to guarantee a distributed transaction was completed?

Question

I've come across a bug using the TransactionScope from the .NET library, where we're getting a TransactionInDoubt exception. After doing a lot of research into something I don't know much about, I've figured this happens when there is a communication error between the database, and we're unsure if the transaction completed.

Trying to handle this error quickly became a pain however, there seem to be a lot of possible problems that arise.

Basically, I want to know if there is a guarantee that a distributed transaction across multiple databases will be committed or rolled-back on ALL databases, not committed on one and not the another.

From my knowledge, the MSDTC controls a distributed transaction and handles this all for me. However reading up on it a little, it seems if there is a communication problem while trying to confirm the commit to one of the databases, then the commit won't be performed for that database, but the others will be committed.

There are plenty of resources online that discuss this, and it's often a lot of conceptual talk, my simple question is: Can I rely on the MSDTC, or do we have to come up with a separate solution to the problem?

Answer 1

Microsoft's DTC developer documentation says

The application programmer's transaction model is simple—programs either succeed or fail. .. When the program reaches a consistent state, it calls the Commit method. If the commit succeeds, the transaction is durably committed. If the commit fails, the transaction aborts.

The Administration Guide offers some more under-the covers information

While a component remains prepared but not committed or aborted, it is in doubt about whether the transaction committed or aborted. If a component or transaction manager fails, it reconciles in-doubt transactions when it reconnects.

So, in the event of a failure a resource (e.g. a database) may be "in doubt". When that database can talk to the cluster again DTC works things out on behalf of the application. If the resource never re-joins the cluster then who cares - that resource is gone and whether it committed or rolled back is neither here nor there.

If someone, somehow manages to talk to that disconnected resource independently of the application or cluster then it may report an incongruous state. It has, after all, been severed from a cluster it expects to be part of.