MSMQ manual transactions
The .NET Framework supports MSMQ transactions in two different ways: manually (internally) by allowing multiple messages to be sent or received as part of a transaction and automatically (externally) by participating in Distributed Transaction Coordinator (DTC) transactions.

MSMQ manual transactions are supported through the MessageQueueTransaction class and are handled entirely inside the MSMQ engine. Please refer to Duncan Mackenzie's article, Reliable Messaging with MSMQ and .NET, for details.

Automatic Transactions
The .NET Framework relies on MTS/COM+ services to support automatic transactions. COM+ uses the Microsoft Distributed Transaction Coordinator (DTC) as a transaction manager and a transaction coordinator to run transactions in a distributed environment. This enables a .NET application to run a transaction that combines diverse activities across multiple resources such as inserting an order into a SQL Server database, writing a message to a Microsoft Message Queue (MSMQ) queue, sending an e-mail message, and retrieving data from an Oracle database.

By providing a programming model based on declarative transactions, COM+ makes it very simple for your application to run transactions that span heterogeneous resources. The caveat is that it pays a performance penalty due to DTC and COM interoperability overhead and there is no support for nested transactions.

ASP.NET pages, Web Service methods, and .NET classes can be marked to be transactional by setting a declarative transaction attribute.

ASP.NET
<@ Page Transaction="Required">

ASP.NET Web Service
<%@ WebService Language="VB" Class="Class1" %>
<%@ assembly name="System.EnterpriseServices" %>
…
Public Class Class1
Inherits WebService
<WebMethod(TransactionOption := TransactionOption.RequiresNew)> _
Public Function Method1()
…

To participate in automatic transactions, a .NET class must be inherited from the System.EnterpriseServices.ServicedComponent class, which enables it to run inside COM+. When you do this, COM+ interacts with the DTC to create a distributed transaction and also enlists all resource connections behind the scenes. You also need to set a declarative transaction attribute on the class to determine its transactional behavior.

Visual Basic .NET

<Transaction(TransactionOption.Required)> Public Class Class1
Inherits ServicedComponent

Visual C# .NET

[Transaction(TransactionOption.Required)]
public class Class1 : ServicedComponent {
…
}

The transaction attribute for a class can be set to any of the following options:

Disabled—indicates that the object is never created in a COM+ transaction. The object can directly use DTC for transactional support.
NotSupported—indicates that the object is never created in a transaction.
Supported—indicates that the object runs in the context of its creator's transaction. If the object is the root object itself or its creator is not running in a transaction, the object is created without a transaction.
Required—indicates that the object runs in the context of its creator's transaction. If the object is the root object itself or its creator is not running in a transaction, the object is created with a new transaction.
RequiresNew—indicates that the object requires a transaction and the object is created with a new transaction.
The following code shows a .NET class configured to run within COM+, with assembly attributes set to configure the COM+ application properties.

Visual Basic .NET

Imports System
Imports System.Runtime.CompilerServices
Imports System.EnterpriseServices
Imports System.Reflection

'Registration details.
'COM+ application name as it appears in the COM+ catalog
<Assembly: ApplicationName("Class1")>
'Strong name for assembly
<Assembly: AssemblyKeyFileAttribute("class1.snk")>
<Assembly: ApplicationActivation(ActivationOption.Server)>

<Transaction(TransactionOption.Required)> Public Class Class1
Inherits ServicedComponent
Public Sub Example1()
…
End Sub
End Class

Visual C# .NET

using System;
using System.Runtime.CompilerServices;
using System.EnterpriseServices;
using System.Reflection;

//Registration details.
//COM+ application name as it appears in the COM+ catalog
[Assembly: ApplicationName("Class1")]
'Strong name for assembly
[Assembly: AssemblyKeyFileAttribute("class1.snk")]
[Assembly: ApplicationActivation(ActivationOption.Server)]

[Transaction(TransactionOption.Required)]
public class Class1 : ServicedComponent {
[AutoComplete]
public void Example1()
{
…
}
}

<Assembly: ApplicationName("Class1")> specifies the name of the COM+ application to install the components of the assembly into. <Assembly: ApplicationActivation(ActivationOption.Server)> specifies if the COM+ application is a server or library application. The assembly must be installed into the global assembly cache (GAC) using the gacutil command-line tool (GacUtil.exe) when you specify ApplicationActivation(ActivationOption.Server).

You can use the Regsvcs.exe command-line tool to convert the assembly to a type library, and register and install the type library into the specified COM+ application. The tool also configures properties that you have added programmatically to your assembly. For example, if ApplicationActivation(ActivationOption.Server) is specified in the assembly, the tool will create a server application. If an assembly is invoked without being installed with COM+, the run time creates and registers a type library and installs it with COM+. You can see and configure the COM+ application created for your assembly in the Component Services snap-in.

The process to create, register, and use serviced components is covered in detail in Writing Serviced Components in the .NET Framework Developer's Guide.

The following code fragment shows a transactional class configured to run under COM+, which executes two SQL commands within the boundary of a transaction. The first command inserts the order header of an order into the Orders table and returns the OrderId of the newly inserted order, which is used by the second command to insert the detail of the same order into the OrderDetails table. The transaction is aborted if either of the two commands fails to execute thereby preventing the rows from being added to the database.

Visual Basic .NET

<Transaction(TransactionOption.Required)> Public Class Class1
Inherits ServicedComponent

Public Sub Example1()
…
Try
' Create a New Connection
conn = New SqlConnection("ConnString")
' Open the Connection
conn.Open()
' Create a new Command object
cmd = New SqlCommand()
' Insert the Order header
' Set the Command properties
With cmd1
.CommandType = CommandType.StoredProcedure
.CommandText = "InsertOrderHeader"
.Connection = conn
' Add input and output parameters
.Parameters.Add("@CustomerId", SqlDbType.Int)
…
.ExecuteNonQuery()
' Clear the parameters for the next command
.Parameters.clear()
End With

' Insert all the Order details
' Set Command properties
With cmd
.CommandType = CommandType.StoredProcedure
.CommandText = "InsertOrderDetail"
.Connection = conn
' Add parameters
.Parameters.Add("@OrderId", SqlDbType.Int)
…
' Execute the command
.ExecuteNonQuery()
' Repeat the above few lines for each order
detail
End With

' Commit the Transaction
ContextUtil.SetComplete()
Catch
' Rollback the Transaction
ContextUtil.SetAbort()
Finally
' Cleanup Code
End Try
End Sub

Using the System.EnterpriseServices.ContextUtil class, you can obtain information about the COM+ object context. It exposes SetComplete and SetAbort methods to explicitly commit and rollback a transaction respectively. As you might expect, the ContextUtil.SetComplete method is called at the very end of the try block when all the operations have been executed successfully to commit the transaction. Any exception thrown is caught in the catch block where the transaction is aborted using ContextUtil.SetAbort.

You can also cause a serviced component to automatically vote to commit or abort the transaction using the System.EnterpriseServices.AutoComplete attribute class. The component votes in favor of committing the transaction if the method call returns successfully. If the method call throws an exception, the transaction is aborted automatically; you don't need to explicitly call ContextUtilSetAbort. To use this feature, insert the <AutoComplete> attribute before the class method:

Visual Basic .NET

<Transaction(TransactionOption.Required)> Public Class Class1
Inherits ServicedComponent
<AutoComplete()> Public Sub Example1()
…
End Sub
End Class

Visual C# .NET

[Transaction(TransactionOption.Required)]
public class Class1 : ServicedComponent {
[AutoComplete]
public void Example1()
{
…
}
}

The <AutoComplete> attribute offers the easiest way to do transactional programming by allowing you to avoid having to explicitly commit or rollback transactions. You get the exact same functionality the previous example where we explicitly called ContextUtil.SetAbort in the catch block to abort the transaction. The disadvantage is that it is not obvious that transactions are involved at all and may be forgotten when maintaining the code at a later time. Also, it does not allow you to throw a user-friendly message in case you want to when a transaction fails. In such cases you should explicitly catch any exceptions, call ContextUtil.SetAbort, and throw the custom message.

In systems that need transactions to run across MSMQ and other transaction-aware resources such as a SQL Server database, there is no choice but to use DTC or COM+ transactions. DTC coordinates all the resource managers participating in a distributed transaction and also manages activities related to the transaction. Please refer to Duncan Mackenzie's article, Reliable Messaging with MSMQ and .NET, for an example of distributed transaction spanning MSMQ and SQL Server.

Conclusion
Each transaction technique offers trade-offs with respect to application performance and code maintainability. Running a database transaction implemented in a stored procedure offers the best performance as it needs only a single round trip to the database. It also gives the flexibility of explicitly controlling the transaction boundary. Although it provides good performance and flexibility, you need to code in Transact SQL, which is not as easy to code as in .NET.

Manual transactions using ADO.NET transaction objects are easy to code and give you the flexibility of controlling the transaction boundary with explicit instructions to begin and end the transaction. The trade off for this ease and flexibility is that it incurs a performance cost for extra round trips to the database to complete the transaction.

An automatic transaction will be the only choice if your transaction spans multiple transaction aware resource managers which could include SQL Server databases, MSMQ Message Queues, etc. It greatly simplifies the application design and reduces coding requirements. However, since COM+ service does all the coordination work, it may have some extra overhead.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/Bdadotnettransact1.asp?frame=true