TransactionScope: Has it gotten better?

Question

When TransactionScope first came out, I ran into some serious issues getting it to work between my dev machine (XP) and our database server (Windows Server 2003).

When I looked into it more, this appeared to be a tricky and widespread issue that had a chance of becoming a headache in production, so I decided not to handle transactions this way (even though I like the syntax a lot and I really wanted it to work).

Are these problems still out there or is this safe to use? Do you use this regularly now without issues?

Thanks a lot!

Note: It has been a long time now, but I think the issue had something to do with Distribute Transaction Coordinator. I fiddled with it for a long time and was never able to get it working.

Answer 1

Rick Strahl has a great post about transaction scope and LINQ to SQL here. Its context is more LINQ to SQL, but I think that there are some principles that apply which could help you solve your question.

EDIT: to more specifically answer your question, here's what Strahl has to say about TransactionScope:

Traditionally TransactionScope was a .NET wrapper around the Distributed Transaction Coordinator (DTC) but it’s functionality has expanded somewhat. One concern is that the DTC is rather expensive in terms of resource usage and it requires that the DTC service is actually running on the machine (yet another service which is especially bothersome on a client installation).

However, recent updates to TransactionScope and the SQL Server Client drivers make it possible to use TransactionScope class and the ease of use it provides without requiring DTC as long as you are running against a single database and with a single consistent connection string

Answer 2

I have been using TransactionScope for over a year now without any issues. However, the application is an internal application with a very small number of users. Also, the database and application reside on the same server.

Here is some information on TransactionScope and where to look for more information: Whenever you create a TransactionScope object it starts a lightweight transaction. Then as long as you use a single connection/resource that supports lightweight transactions, the transaction will be handled by the resource manager consuming as little resources as possible with very good performance. When you add a second connection/resource into the transaction scope the transaction manager will automatically be promoted to an OleTx Transaction Manager, which can handle distributed transactions by using the COM+ DTC technologies. This will also happen with a single connection to a resource manager that doesn't support lightweight transactions such as SQL Server 7/2000, Oracle and other RDBMSs.

Here are two resources that may be able to help you out:

"Microsoft Windows Server 2003 Service Pack 1 (SP1) and Microsoft Windows XP Service Pack 2 (SP2) include many security-related updates and changes. Some of these changes affect the Microsoft Distributed Transaction Coordinator (MSDTC) service." New functionality in the Distributed Transaction Coordinator service in Windows Server 2003 Service Pack 1 and in Windows XP Service Pack 2

and

Juval Lowy's whitepaper on System.Transactions: Introducing System.Transactions in the Microsoft .NET Framework version 2.0