.NET Enterprise Services

Who takes care of these distributed transactions? In Windows it is the job of the Distributed Transaction Coordinator (DTC), which is part of the COM+ system. In .NET the .NET Enterprise services are wrapped around COM+. They allow creating objects that way that the creating context does not get the object itself, but a so-called Proxy that intercepts all calls into the object. Thus it is possible to put every call to the objects in a transaction context that records certain activities.

The recorded activities include all calls to data layers like ADO, OleDB or ADO.NET. The DTC records not only the data access caused by the object itself but also the access of all other objects which are created by the first object. That way a complete object tree can participate in a transaction automatically. The root of the tree is called transaction root.

The transaction root and all the objects it creates have access to the transaction context and can commit or abort a transaction using the transaction context (SetComplete(), SetAbort()) or can influence the outcome of a transaction (TransactionVote()).

A transaction runs from the first recorded data access until SetComplete() or SetAbort() are called. In case of SetComplete() the two phase commit protocol is started for all connections where an access was recorded. In the case of SetAbort() an abort command is sent to all connections.

NDO supports that concept and wraps the Enterprise services in own classes as described below.

Local Transactions or .NET Enterprise Services?

As shown above, ADO.NET supports two transaction models: local transactions that are limited to a single data source, and distributed transactions that run with .NET enterprise services. The question is: Which one should you use?

If your transactions are always limited to exactly one data source, you should use local transactions. They are faster and more flexible. You always have the possibility to encapsulate different activities in different transactions running against different data connections.

If you can’t avoid different operations having to be enclosed in a single transaction or if you need to use certain features of the .NET Enterprise Services, you should use distributed transactions.