• Choose a category
• All
• Classic-Fiction

StateServer

The values for all the sessions are serialized and stored in the memory of a separate system process ( aspnet_state.exe). The process can also run on another machine. Session values are deserialized into the session dictionary at the beginning of the request. If the request completes successfully, state values are serialized into the process memory and made available to other pages.

The SessionStateMode enum type lists the available options for the state client provider. The InProc option is by far the fastest possible in terms of access. However, bear in mind that the more data you store in a session, the more memory is consumed on the Web server, which increases the risk of performance hits. If you plan to use any of the out-of-process solutions, the possible impact of serialization and deserialization should be carefully considered. We’ll discuss this aspect in detail later in the Persist Session Data to Remote Servers section.

The session-state module determines the state provider to use based on what it reads out of the section of the web.config file. Next, it instantiates and initializes the state provider for the application. Each provider continues its own initialization, which is quite different depending on the type. For example, the SQL Server state manager opens a connection to the given database, whereas the out-of-process manager checks the specified TCP port. The InProc state manager, on the other hand, stores a reference to the callback function that will be used to fire the Session_End event. (I’ll discuss this further in the section Lifetime of a Session.)

Creating the HttpSessionState Object

The state module is responsible for retrieving the session state and attaching it to the context of each request that runs within the session. The session state is available only after the HttpApplication.AcquireRequestState event fires, and it gets irreversibly lost after the HttpApplication.ReleaseRequestState event. Subsequently, this means that no state is still available when Session_End fires.

The session module creates the HttpSessionState object for a request while processing the HttpApplication.AcquireRequestState event. At this time, the HttpSessionState object—a sort of collection—is given its session ID and the session dictionary. The session dictionary is the actual collection of state values that pages will familiarly access through the Session property.

If a new session is being started, such a data dictionary is simply a newly created empty object. If the module is serving a request for an existing session, the data dictionary will be filled by deserializing the contents supplied by the currently active session state provider. At the end of the request, the current content of the dictionary, as modified by the page request, is flushed back to the state provider through a serialization step. The whole process is depicted in Figure 17-1.

Figure 17-1. The session state management timeline.

Synchronizing Access to the Session State

So when your Web page makes a call into the Session property, it’s actually accessing a local, in-memory copy of the data. What if other pages (in the same session) attempt to concurrently access the session state? In that case, the current request might end up working on inconsistent data or data that isn’t up to date.

To avoid that, the session state module implements a reader/writer locking mechanism and queues the access to state values. A page that has session-state write access will hold a writer lock on the session until the request finishes. A page gains write access to the session state by setting the EnableSessionState attribute on the @Page directive to true. A page that has session-state read access—for example, when the EnableSessionState attribute is set to ReadOnly—will hold a reader lock on the session until the request finishes.

If a page request sets a reader lock, other concurrently running requests cannot update the session state but are allowed to read. If a page request sets a writer