Programming WCF Services, 3rd Edition

Instance Management and Transactions

As hinted previously, the transactional configuration of the service is intimately related to the service instance lifecycle, and it drastically changes the programming model. All transactional services must store their state in a resource manager or managers. Those resource managers could be volatile or durable, shared between the instances or per instance, and could support multiple services, all according to your design of both the service and its resources.

Volatile Resource Managers

In the article “Volatile Resource Managers in .NET Bring Transactions to the Common Type” (MSDN Magazine, May 2005), I presented my technique for implementing a general-purpose volatile resource manager called Transactional<T>:

public class Transactional<T> : ...
{
   public Transactional(T value);
   public Transactional();
   public T Value
   {get;set;}

   /* Conversion operators to and from T */
}

By specifying any serializable type parameter (such as an int or a string) to Transactional<T>, you turn that type into a full-blown volatile resource manager that auto-enlists in the ambient transaction, participates in the two-phase commit protocol, and isolates the current changes from all other transactions using my original transaction-based lock.

For example, in the following code snippet, the scope is not completed. As a result the transaction aborts, and the values of number and city revert to their pre-transaction state:

Transactional<int> number = new Transactional<int>(3); ...