Programming WCF Services, 2nd Edition

Service State Management

The sole purpose 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 benefits 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, which means that if the transaction aborts the system will not be left in a consistent state. The problem is compounded by the fact that any transaction a service participates in may span multiple services, machines, and sites. Even if that service instance encounters no errors and votes to commit the transaction, other parties across the service boundary may eventually abort the transaction. 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 had made to its state?

The solution to this 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 not the same as a stateless ...