This post was migrated from an older system. Some links may point to content that no longer exists. Comments were not migrated.
Session state is an interesting feature when used in combination with Windows® SharePoint® Services. By default, session state is not enabled. If you open the web.config file for your SharePoint virtual server, you would find the following commented line in the <httpModules> section:
<!--<add name="Session" type="System.Web.SessionState.SessionStateModule"/>-->
Can SessionState be enabled?
Yes. To enable SessionState, all you would need to do is to uncomment the line. However, doing so may adversely affect the performance of your server.
SessionState can adversely affect my server?
Yes - it all hinges upon whether or not the SafeMode parser is called.
Session state is one of those areas where SharePoint’s SafeMode parser differs from Asp.net. The difference in behavior is not subtle.
In a vanilla Asp.net site once SessionState is enabled, each page can elect whether or not to use session state. The opt-in functionality offers pages which do not require session state the ability to avoid the performance hit associated with session state.
With the SafeMode parser, this opt-in option does not exist. Once SessionState is enabled for the virtual server, all pages processed by the SafeMode parser are forced to use session state. That’s right – every unghosted aspx page is forced to use session state whether or not controls on that page require session state!!
Session state can be quite taxing on your system depending on how it is setup. Knowing that every unghosted page is forced to use session state once it is turned on, it becomes extremely important to take full stock of the ratio of ghosted to unghosted pages on your system.
Let's look at an example ...
Assume your SharePoint server contains mostly unghosted pages. Let’s say there are 1000 unghosted pages on the site. You create a web part that requires session state. Let’s say that web part is only used on a few select pages (i.e. 2-3 pages). Enabling session state so that 2-3 pages can use the web part suddenly slows down the performance of the 998 other pages.
In this example, it's easy to see why enabling SessionState is not beneficial. If you were to flip the scenario around just a bit such that most pages are ghosted and the SessionState-requiring WebPart is used on a large number of pages, then SessionState would not have as much unintended negative impact.
Do alternatives exist?
Items which need to travel between requests can be stored in ViewState, the WebPart cache, WebPart properties, and SessionState. The key point to remember is that unlike other options, session state will cause system-wide perf degradation simply because each page will have a session object attached whether or not it wants it.
References
Ghosted and unghosted pages - part 1 of 2
http://www.bluedoglimited.com/SharePointThoughts/lists/posts/post.aspx?ID=4
ASP.NET Session State: Architectural and Performance Considerations
http://blogs.msdn.com/tims/archive/2003/11/21/57453.aspx
WebParts and Caching
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/spptsdk/html/smpxCaching.asp