Designing a WCF Service to Support Transactions

The previous sections have shown you how to implement transactions in a WCF service, but there are a number of issues you should be aware of when designing a WCF service that requires transactions.

Transactions and Service Instance Context Modes

If you set the TransactionAutoComplete property of the OperationBehavior attribute of one or more methods in a WCF service to false, you must use the PerSession service instance context mode. This is because the WCF runtime needs to maintain transactional state between calls to operations. If you set the TransactionAutoComplete property to true for every operation, the WCF runtime does not need to maintain transactional state as it completes the current transaction at the end of each operation, and you can use the PerCall and Single service instance context modes.

If you use the PerSession instance context mode, WCF provides two additional properties you can specify as part of the ServiceBehavior attribute:

• ReleaseServiceInstanceOnTransactionComplete. If you set this property to true, the WCF runtime will automatically end the session and recycle the service instance at the end of each transaction. If a client application invokes another operation, it must create and connect to a new instance of the service, as described in Chapter 7. Setting this property to false allows a session to handle multiple transactions. The default value of this property is true.

• TransactionAutoCompleteOnSessionClose. If you set this property to true, the WCF runtime will automatically complete the current transaction when the client application closes the session. The default value for this property is false.

Transactions and Messaging

A transactional operation sends information back to the client application about the state of the transaction. All the operations that you have defined so far have followed the request/ response model; the client application sends a request and waits for a response from the service. You will see in Chapter 11, “Invoking WCF Service Operations Asynchronously,” that you can define one-way operations that do not send a response back to the client application. One-way operations cannot be transactional.

Transactions and Multi-Threading

You saw in Chapter 7 that a WCF service can enable multiple concurrent calls to operations if you set the ConcurrencyMode property of the ServiceBehavior attribute to ConcurrencyMode.Multiple. You should note the following points when attempting to use this mode:

• The TransactionAutoComplete property of the OperationBehavior attribute must be set to true for every operation in the service. Transactions cannot span multiple operations.

• The ReleaseServiceInstanceOnTransactionComplete property of the ServiceBehavior attribute for the service must be set to false. You must explicitly release the service instance by closing the connection from the client.

• The TransactionAutoCompleteOnSessionClose property of the ServiceBehavior property for the service must be set to true. All transactions on all threads must be terminated when the session closes.

Long-Running Transactions

Transactions lock resources. To minimize the impact on other users and to maintain throughput and concurrency, you should design transactions to be as short-lived as possible. Avoid performing tasks such as waiting for user input while executing a transaction.

In a business-to-business scenario, this is not always possible. It is common for inter-business transactions to take a considerable period of time (possibly days). Such long-running transactions require you to adopt an alternative strategy. The most common solution is for a service to perform any updates and release any locks on resources immediately, effectively treating each modification as a singleton transaction in its own right. The service should maintain a list of changes it has made. At some later point, if the service needs to rollback these changes, it can consult this list and perform updates that reverse their effect. This undo operation is sometimes referred to as a “compensating transaction.”

Using compensating transactions has a number of issues. For example, it might not be possible to undo an operation if another user has made further changes in the interim. Additionally, other users can see the changes that have been made, so if you undo these changes, other users’ transactions might cause some inconsistencies.

Detailed discussion of creating and rolling back long-running transactions is outside the scope of this book, but Microsoft provides support for defining compensating transactions by using Windows Workflow Foundation.

More Info 

For further details about Microsoft Windows Workflow Foundation, see the Windows Workflow Foundation Web site at http://msdn.microsoft.com/winfx/technologies/workflow/default.aspx.