Transactions in ASP.NET XML Web Services
This topic is specific to a legacy technology. XML Web services and XML Web service clients should now be created using Windows Communication Foundation.
The transaction support for Web services leverages the support found in the common language runtime, which is based on the same distributed transaction model found in Microsoft Transaction Server (MTS) and COM+ Services. The model is based on declaratively deciding whether an object participates in a transaction, rather than writing specific code to handle committing and rolling back a transaction. For a Web service created using ASP.NET, you can declare its transactional behavior by setting the TransactionOption property of the WebMethod attribute applied to a Web service method. For an example, see How to: Participate in Transactions in Web Services Created Using ASP.NET.
If an exception is thrown while the Web service method is executing, the transaction is automatically aborted; conversely, if no exception occurs, the transaction is automatically committed.
The TransactionOption property of the WebMethodAttribute attribute specifies how a Web service method participates in a transaction. Although this declarative level represents the logic of a transaction, it is one step removed from the physical transaction. A physical transaction occurs when a transactional object accesses a data resource, such as a database or message queue. The transaction that is associated with the object automatically flows to the appropriate resource manager. A .NET Framework data provider, such as the .NET Framework Data Provider for SQL Server or the .NET Framework Data Provider for OLE DB, looks up the transaction in the object's context and enlists in the transaction through the Distributed Transaction Coordinator (DTC). The entire transaction occurs automatically.
Web service methods can participate in a transaction only as the root of a new transaction. As the root of a new transaction, all interactions with resource managers, such as servers running Microsoft SQL Server, Microsoft Message Queuing (also known as MSMQ), and Microsoft Host Integration Server maintain the ACID properties required to run robust distributed applications. Web service methods that call other Web service methods participate in different transactions, because transactions do not flow across Web service methods.
Note
When the method that implements the Web service method is not called due to an Internet request for the file with an .asmx extension in which it resides or is associated with, the value of the TransactionOption property has no effect. This can happen when the class in which the method resides is a member of a project within Visual Studio .NET and the Web service is not invoked using a proxy class. In Visual Studio .NET, a proxy class is generated when a Web Reference is added.
See Also
Tasks
How to: Participate in Transactions in Web Services Created Using ASP.NET
Reference
TransactionOption Enumeration
WebMethodAttribute.TransactionOption Property