What is MSDTC and why do I need to care about it?

I’ve been talking for a while about MSDTC and transactions without explaining them. I know
many of you reading this blog already know the terms, but some of the developers just
entering the enterprise space don't know if they should care or not about these subjects.
MSDTC is an acronym for Microsoft Distributed Transaction Coordinator. As the name says,
MSDTC is a Windows service providing transaction infrastructure for distributed systems. In
this case, a transaction means a general way of structuring the interactions between
autonomous agents in a distributed system. Each transaction is a state transformation with
four key properties - the ACID properties: Atomic (all or nothing), Consistent (legal), Isolated
(independent of concurrent transactions) and Durable (once it happens, it cannot be
abrogated). There are different techniques that implement the ACID properties but the most
known one is two-phase commit.
In other words, transaction processing is a software technology that makes distributed
computing reliable. You can see a transaction as a unit of work in which a series of operations
occur. The transaction (with its ACID properties) is providing protection in the case when one
or more of these operations fail at any point in time. By using transactions, you can vastly
simplify the error recovery for your system.
The main actors in a transaction are: the transaction manager (MSDTC), the initiator (the
application which started the transaction) and the resource managers (the entities that
manage data and work). The flow of actions in a simplified form is:
1. The client application (the initiator) begins a transaction by requesting one from the
transaction manager;
2. The client app asks the resource managers to do work as part of the same transaction;
during this step, the resource managers register with the transaction manager for that
transaction ("they enlist");
3. The client app commits the transaction;
4. The transaction manager coordinates with the resource managers to ensure that all
succeed to do the requested work or none of the work if done, thus maintaining the ACID
properties.

The main transactions standard currently supported by MSDTC is the OLE Transactions (or
OleTx). MSDTC is also supporting other standards like XA (or X/Open Distributed Transaction
Processing Standard) and TIP (Transaction Internet Protocol). In the future MSDTC will
support WS-Coordination, WS-AtomicTransaction, and WS-BusinessActivity.

You can read more about MSDTC at http://msdn.microsoft.com/library/?url=/library/en-

us/cossdk/htm/dtc_toplevel_6vjm.asp?frame=true.
If you are developing COM+ or System.EnterpriseServices components and you are using the
Transaction service then you are indirectly using MSDTC. The COM+ infrastructure is hiding
all the details from you so you can focus on your business needs instead of implementation
details. If you need to bypass COM+ and talk directly to MSDTC you can do it using the MSDTC
proxy (msdtcprx.dll). For now, to directly access MSDTC from .Net apps you need to use COM
Interop. For future apps, please refer to my previous post about .Net and Transactions.
Tags COM+ Enterprise Services MSDTC Transactions

ACID Properties
Coined by transaction processing pioneers, the acronym ACID stands for atomic, consistent,
isolated, and durable. To ensure predictable behavior, all transactions must possess these
basic properties, reinforcing the role of mission-critical transactions as all-or-none
propositions.

The following list containss a definition and a description of each ACID property:

Atomic

A transaction must execute exactly once and must be atomic—either all of the work is done
or none of it is. Operations within a transaction usually share a common intent and are
interdependent. By performing only a subset of these operations, the system could
compromise the overall intent of the transaction. Atomicity eliminates the chance of
processing only a subset of operations.

Consistent

A transaction must preserve the consistency of data, transforming one consistent state of
data into another consistent state of data. Much of the responsibility for maintaining
consistency falls to the application developer.

Isolated

A transaction must be a unit of isolation, which means that concurrent transactions should
behave as if each were the only transaction running in the system. Because a high degree of
isolation can limit the number of concurrent transactions, some applications reduce the
isolation level in exchange for better throughput. See Configuring Transaction Isolation
Levelsfor more information.

Durable

A transaction must be recoverable and therefore must have durability. If a transaction

commits, the system guarantees that its updates can persist even if the computer crashes
immediately after the commit. Specialized logging allows the system's restart procedure to
complete unfinished operations required by the transaction, making the transaction durable.
System.Transactions and Allow Inbound/Outbound DTC
Settings
If you do distributed transactions across the network, you know about Allow Inbound and
Allow Outbound security settings for DTC (available by running dcomcnfg or by opening
Component Services).
The help describes these settings as:

 Allow Inbound: Select this check box to allow a remote computer to flow transactions to
the local computer. Typically, this option is needed on the computer that is hosting the
DTC for a resource manager such as Microsoft SQL Server.

 Allow Outbound: Select this check box to allow the local computer to flow transactions to
a remote computer. Typically, this option is needed on the client computer, where the
transaction is initiated.

Pretty straightforward: you set Allow Outbound on the client and Allow Inbound on the SQL
Server box. Except, if you are using System. Transactions with SQL Server and you promote
after the first connection to the database (which means DTC gets involved), the transaction
will most likely abort. Why?
If you remember my previous post on promotable transactions, in this case, the distributed
transaction gets initiated on the resource manager (SQL Server) side and gets flown back to
the client, which means that you actually need to set Allow Outbound on the SQL Server box
and Allow Inbound on the client.
I know, it's not the most intuitive setting. Allow Inbound/Outbound were created before
System.Transactions, they are still doing what they were designed to do, except that they
didn't evolve with System.Transactions.
When System.Transactions was being designed, between other goals one important one was
to make it easy to use. And with that, the promotion part was supposed to be as invisible as
possible - things will go fast, then on demand promote to DTC and continue without any user
intervention. The legacy of managing DTC network settings couldn't be avoided and thus all
these details had to be explained.
Tags promotable transactions System.Transactions DTC Inbound Outbound