Not all ASP.NET pages ultimately use the session state; and not all of the pages that make use of the session state actually update it. For too many times, I've seen Web pages that enable full access to session state for all pages when only a few of them actually read or write it. Session state, as you may know, is not free of charge in raw terms of performance.
It's probably been stated a zillion times already, but let's recall it once more -- HTTP is a stateless protocol. This means that nothing is remembered across two successive calls to the same page or server. Because the Web came after people built stateful client applications for decades, it was reckoned that offering a system tool for doing stateful programming over a stateless protocol was ultimately a good thing. Enter session state.
In ASP.NET, session state is implemented through a HTTP module that kicks in at a known stage in the request lifecycle and attaches to request context any state information that is relevant to the current session.
Session state, therefore, is not a complimentary good but comes at a cost. It's maybe a bill that you don't pay directly, but still a regular bill.
The HTTP module for session state hooks up any requests, determines the storage for session state, retrieves it and attaches data to the HTTP context of the current request. This happens right before the page is instantiated and the code-behind class executes. From this point onward, the page will be able to access any piece of the session state through the familiar Session object.
It's easy to see that attaching session state to a request involves data retrieval and, in some cases, data transfer across the boundaries of processes. The session state storage is specified in the application's configuration file, as below:
<sessionState
mode="Off|InProc|StateServer|SQLServer" />
The value of the mode attribute indicates the type of storage. InProc means that the session state is kept in the memory space of the worker process-specifically in an internal slot of the Cache object. StateServer indicates that an external process will be used. SQLServer indicates that the storage is actually an ad hoc table in a SQL Server database. So when your Web page makes a call into the Session property, it's actually accessing a local, in-memory copy of the data. Are there any concurrency issues to be aware of?
The session state module implements a 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.
<% @Page EnableSessionState="ReadOnly" %>
Concurrent access to the session state might happen if you have a multi-frame page or if your users work with two copies of the same page or multiple pages of the same application at the same time. It also happens when you use session-enabled HTTP handlers to serve embedded resources such as images or CSS files.
Declaring exactly the use of the session state that each page is going to make is a way to optimize the performance of the page and also a way to keep the code clean.
