Working with Session State

One concept that sometimes confuses ASP.NET developers when moving to WCF is the notion of session state. In ordinary WCF services, all of the session state is stored in local volatile memory. The application has to choose to copy over a portion of the session state to a durable storage location for that state to be preserved across running instances. WCF doesn't come with a built-in option for enabling persistent storage of session state or enabling access to the session state from other processes.

There are a couple ways to make WCF more like ASP.NET.

One way to make WCF more like ASP.NET is to make WCF exactly like ASP.NET by turning on ASP.NET compatibility mode. A WCF application that is hosted in IIS and uses HTTP as a transport binding runs together with the ASP.NET pipeline but does not have access to many of the ASP.NET features. Turning on compatibility mode integrates the WCF application with the ASP.NET pipeline and makes many of those features available. Obviously, this approach is only interesting when your WCF service is already very much like an ASP.NET application.

Another way to make WCF more like ASP.NET is to change the management of WCF session state to use remote durable storage rather than local volatile memory. This approach is more like the one used by workflow services to create durable applications. The management of service instances and instance contexts is controlled by the IInstanceProvider that creates and destroys service objects, the IInstanceContextProvider that creates and destroys instance contexts, and the IInstanceContextInitializer that sets up newly acquired instance contexts. Although durable services have different semantics than session state, there are common building blocks that can be used for both.

Next time: Diagnosing Common Queue Errors

Comments

• Anonymous
  October 08, 2008
  Security and streaming are two features that often do not get along with each other. Although the concepts