Live Chat Icon For mobile
Live Chat Icon

ASP.NET FAQ - Session

Find answers for the most frequently asked questions
Expand All Collapse All

Depends on which mode you are using:

  • InProc Mode- objects stored in session state are actually live objects, and so you can store whatever object you have created.
  • State Server or SQL Server mode, objects in the session state will be serialized and deserialized when a request is processed. So make sure your objects are serializable and their classes must be marked as so. If not, the session state will not be saved successfully. In v1, there is a bug which makes the problem happen unnoticed in SQLServer mode and will make your request hang. The hanging problem is fixed in v1.1. The fix for KB 324479: ASP.NET SQL Server Session State Impersonation Is Lost Under Load also contains the fix for this problem. The problem will be fixed in v1 SP3 too.

    For more info: BUG: Session Data Is Not Saved in Out-of-Process Session State


This problem may occur after you install Windows Sharepoint Server(WSS) on a server that has Microsoft Visual Studio .NET 2003 installed. The WSS ISAPI filter handles all incoming URLs. When you browse one of the ASP.NET Web application virtual directories, the ISAPI filter does not locate the URL path of the folder.
To resolve this refer Session state cannot be used in ASP.NET with Windows SharePoint Services


Setting Cookieless=true implies some restrictions, mainly:

  1. You cannot use absolute link in your pages.
  2. You have to perform additional steps to switch between http and https pages in your application.
  3. If your customer sends a link to a friend, the URL will contain the session ID and both users could be using the same session ID at the same time.

The reason is that your frameset page is an HTM file instead of an ASPX file.

In normal a scenario, if the frameset is an aspx file, when you request the page, it will first send the request to the web server, receive an session cookie (which holds the session id), and then the browser will send individual requests for the frames, and each request will carry the same session id.

However, since your frameset page is an htm file, the first request comes back without any session cookie because the page was serviced by ASP and not ASP.NET. Then again your browser sends out individual requests for each frame. But this time each individual request will NOT carry any session id, and so each individual frame will create its own new session. That’s why you will see different session ids in each frame. The last request that comes back will win by overwriting the cookie written by the previous two requests. If you do a refresh, you will see them having the same session id.

This behavior is by-design, and the simple solution is to change your frameset page to .aspx.



Dim strKey as string
For Each strKey In Session.Keys
Response.Write(strKey + ' : ' + Session(strKey).ToString() + '<br>')


foreach (string strKey in Session.Keys) 
Response.Write(strKey + ' : ' + Session[strKey].ToString() + '<br>'); 

Session state implements a reader/writer locking mechanism:

  • A page (or frame) that has session state write access (e.g. <%@ Page EnableSessionState=’True’ %>) will hold a writer lock on the session until the request finishes.
  • A page (or frame) that has session state read access (e.g. <%@ Page EnableSessionState=’ReadOnly’ %>) will hold a reader lock on the session until the request finishes.
  • Reader lock will block a writer lock; Reader lock will NOT block reader lock; Writer lock will block all reader and writer lock.
  • That’s why if two frames both have session state write access, one frame has to wait for the other to finish first


Dim x As New SortedList()
x.Add('Key1', 'ValueA')
x.Add('Key2', 'ValueB')

To store in Session:

Session('SortedList1') = x 

and to retrieve

Dim y As SortedList = CType(Session('SortedList1'), SortedList)


SortedList x = new SortedList();
x.Add('Key1', 'ValueA');
x.Add('Key2', 'ValueB');

To store in Session:

Session['SortedList1'] = x;

and to retrieve

SortedList y = (SortedList) Session['SortedList1'];
  1. Session_End is supported only in InProc mode.
  2. Session_End is run using the account which runs the worker process (aspnet_wp.exe), which can be specified in machine.config. Therefore, in your Session_End, if you connect to SQL using integrated security, it will use that worker process account credential to connect, and may fail depending on your SQL security settings.
  • – First, check your web.config, machine.config and your page directive to make sure you have enabled session state.

  • – session state is not available just everywhere, anytime. It is available only after the HttpApplication.AcquireRequestState event is called. For example, it is NOT available in the Application_OnAuthenticateRequest handler inside global.asax.
    For details, see: Handling Public Events
  • – Lastly, make sure System.Web.SessionState.SessionStateModule is included the in your config files. A common case is that SharePoint application will remove this module from their web.config files (for performance reason), and thus session state isn’t available.

Share with

Couldn't find the FAQs you're looking for?

Please submit your question and answer.