Programming WCF Services

Service State Management

The sole propose of transactional programming is to address the recovery challenge by always leaving the system in a consistent state. The state of the system consists of all the resources that were involved in the transaction plus the in-memory clients and service instances. Besides the advantage of a WCF resource manager such as auto-enlistment and participation in the two-phase commit protocol, the basic and obvious advantage of using a resource manager is that any change made to its state during a transaction will automatically roll back if the transaction aborts. This, however, is not true when it comes to the in-memory instance members and static members of the participating services. Consequently, the system would not be in a consistent state after the transaction. The problem is compounded by the fact that the transaction the service participates in may span multiple services, machines, and sites. Even if the service instance encounters no errors and votes to commit transaction, the transaction may eventually be aborted by other parties across the service boundary. If the service were to simply store its state in memory, how would it know about the outcome of the transaction so that it would somehow manually roll back the changes it made to its state?

The solution for the service instance state management problem is to develop the service as a state-aware service and proactively manage its state. As explained in Chapter 4, a state-aware service is ...