Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼


ReadOnly Sessions and ASP.NET

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:

    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.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.