Suppress Transaction Scope

This topic applies to Windows Workflow Foundation 4 (WF4).

The sample demonstrates how to author a custom SuppressTransactionScope activity to suppress the ambient run-time transaction, if present.

Sample Details

The custom activity is useful to prevent a transaction from being flowed out to another service if transaction flow is undesirable for the particular scenario. The workflow runtime has built-in support for suppressing the ambient transaction in the NativeActivity class, but to use this support it is necessary to author a custom NativeActivity such as the one in this sample.

The scenario consists of three parts. First, a TransactionScope creates a run-time transaction that becomes ambient. This is verified by a custom activity that prints the local and distributed identifiers of the transaction. The transaction is then flowed to a remote service before beginning the second part. During the second part, the workflow enters a SuppressTransactionScope and again repeats the process of printing the transaction identifiers and flowing the transaction. However, the custom activity does not find an ambient transaction and the message flowed to the service does not contain the transaction. As a result, the service creates a transaction, which means the distributed ID printed on the client and service do not match. The final part occurs after the SuppressTransactionScope exits and the run-time transaction again becomes ambient as verified by another message to the service with a distributed identifier that matches the identifier of the first message.

The activity itself derives from NativeActivity because it must schedule a child activity and add an execution property. The SuppressTransactionScope has a Variable of type RuntimeTransactionHandle, which must be used rather than an instance field of type RuntimeTransactionHandle because the handle must be initialized. The Variable<RuntimeTransactionHandle> is added to the activity’s metadata as an implementation variable because it is only used internally.

When the activity is executed it first checks to see whether a body was specified and if so, sets the SuppressTransaction property on the RuntimeTransactionHandle. Once the property is set, it is added to the execution properties and becomes ambient. This means that any activity that is a child of the SuppressTransactionScope is able to see the property and therefore enforces the suppression of the run-time transaction and causes a nested TransactionScope to throw an exception. Once the handle is added to the execution properties the body is scheduled to run.

To use this sample

1. Open the SuppressTransactionScope.sln solution in Visual Studio 2010.

2. To build the solution, press CTRL+SHIFT+B or select Build Solution from the Build menu.

3. Once the build has succeeded, right-click the solution and select Set Startup Projects. From the dialog, select Multiple Startup Projects and ensure the action for both projects is Start.

4. Press F5 or select Start Debugging from the Debug menu. Alternatively, you can press CTRL+F5 or select Start Without Debugging from the Debug menu to run without debugging.

   Note

   The server must be running prior to starting the client. The output from the console window that hosts the service indicates when it has started.

Note:

The samples may already be installed on your computer. Check for the following (default) directory before continuing. <InstallDrive>:\WF_WCF_Samples If this directory does not exist, go to Windows Communication Foundation (WCF) and Windows Workflow Foundation (WF) Samples for .NET Framework 4 to download all Windows Communication Foundation (WCF) and WF samples. This sample is located in the following directory. <InstallDrive>:\WF_WCF_Samples\WF\Scenario\Transactions\SuppressTransactionScope