ASP.NET FAQ - Session

Yes.
For more details Refer HOW TO: Configure ASP.NET for Persistent SQL Server Session State Management

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

Include a sql trusted connection, or put the connection string as encrypted data in the registry.
Refer

• FIX: Stronger Credentials for processModel, identity, and sessionState
• How To Use the ASP.NET Utility to Encrypt Credentials and Session State Connection Strings

Yes.
Refer FIX: Using one SQL database for all applications for SQL Server session state may cause a bottleneck

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

This can be due to application recycle.
See PRB: Session variables are lost intermittently in ASP.NET applications
In v1, there is also a bug that will cause worker process to restart. It’s fixed
in SP2 and v1.1. See FIX: ASP.NET Worker Process (Aspnet_wp.exe) Is Recycled Unexpectedly.

No. This MSDN article shows how to work around it:
How to Share Session State Between Classic ASP and ASP.NET

(Right answer?)
Refer What kind of objects can I store in Session State?

Here is an article from ftp online: Simplify State Maintenance With ASP.NET

Here is an article from ftp online: Manage Session State on the Client that describes how Cookies, Hidden Fields and Query Strings can be used to preserve session state.

Here is an article from ftp online: Manage Session State on the Server.

Here is an article from ftp online: Display and Manage Images in ASP.NET

Client state can be managed in different ways, session state, view state or using cookies.
Here is an article from ftp online: Manage Client State that discusses this in more detail.

Your HttpHandler has to implement the ‘marker’ interface IRequiresSessionState or IReadOnlySessionState in order to use session state.

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.

You will have the HttpSessionState object available. Just use ’Session’ to access it.

For HttpContext, it is not available because this event is not associated with any request.

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 asp.net 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.

• In II5, it’s stored in the memory of aspnet_wp.exe.
• For IIS6, by default all apps will share the same application pool, i.e. the session state is stored in the memory of the process w3wp.exe. They are NOT separated per application, but instead per application pool (w3wp.exe)

The SessionID lasts as long as the browser session lasts even though the session state expires after the indicated timeout period i.e the same session ID can represent multiple sessions over time where the instance of the browser remain the same.

The session Timeout is a sliding expiration time, meaning whatever your page access session state, the expiration time will be moved forward. Note that as long as a page has NOT disabled session state, it will access the session automatically when requested.

VB.NET

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

C#

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

VB.NET

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)

C#

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'];

The Timeout setting is in minutes, not in seconds. i.e The timeout attribute specifies the number of minutes a session can be idle before it is abandoned. The default is 20

Use HttpSessionState.Remove()

No

Use HttpContext.Current.Session i.e
VB.NET

HttpContext.Current.Session('CustID') = '1'

C#

HttpContext.Current.Session['CustID'] = '1';

Use HttpContext.Current.Session

VB.NET

HttpContext.Current.Session('Value1') = '1'

C#

HttpContext.Current.Session['Value1'] = '1';

In similar manner you can use Application Variables too.

Even those enableSessionState is marked as ReadOnly, but in InProc state, the user can still modify the session. The only difference is that the session will not be locked during the request. This limitation is by-design

In SQLServer mode, session expiration is carried out by the SQL Agent using a registered job. Make sure your SQL Agent is running.

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.

When using cookieless, you must use relative path (e.g. ..\webform1.aspx) instead of absolute path (e.g. \dir1\subdir1\webform1.aspx). If you use absolute path, ASP.NET cannot preserve your session ID in the URL.

It depends on which event you’re handling. Session is available only after AcquireRequestState event

Session_End is fired internally by the server, based on an internal timer. And thus there is no HttpRequest associted when that happens. That is why Response.Redirect or Server.Transfer does not make sense and will not work.

The major difference is that if you call Session.Abandon(), Session_End will be fired (for InProc mode), and in the next request, Session_Start will be fired.
Session.Clear( ) just clears the session data without killing it.

No.

• – First, check your web.config, machine.config and your page directive to make sure you have enabled session state.
  Reference:
  • Session State
  • @ Page
• – 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.