Session State in Asp.net

Web-based programming distinguishes itself as a programming idiom in which you try to manage an application serving multiple users distributed over a wide area. So, we need to have particular sort of data such as username for all different active users to provide the file and services for that are meant for them. To do this we require, data-holding area that persists for the lifetime of a single user’s session. This type of data is known as session state.



The Session object is a dictionary of name/value pairs. You can associate any Common Language Runtime (CLR)-based object with a key of your choosing and place it in the Session object so that it will be there when the next request belonging to that session comes through. Then, you can access that piece of data using the key under which it was stored.

For Example:

If you want to store some information provided by the user in the Session object, you can write code like this:

void StoreInfoInSession()
{
String strFromUser = TextBox1.Text;
Session["strFromUser"] = strFromUser;
}  

// To retrieve the string during the next request, use code like this: 

void GetInfoFromSession()
{
String strFromUser = Session["strFromUser"] ; // NOTE: may be null
TextBox1.Text = strFromUser;
}

The brackets on the Session object indicate an indexer. The indexer is a convenient syntax for expressing keys—both when inserting data into and retrieving data from the Session object.


 In ASP.NET, session state can live in a number of places, including
(1) “in proc”—in the ASP.NET worker process,
(2) on a separate state server running a Windows Service process, and
(3) in a Microsoft SQL Server database.

Configuring Session State

Don’t use it at all.        By disabling session state, your application performance will increase because the page doesn’t need to load the session when starting, and neither does it need to store session state when it’s going away. On the other hand, you won’t be able to associate any data with a particular user between page invocations.

 Store session state “in proc.”   This is how session state is handled by default. In this case, the session dictionaries (the Session objects) are managed in the same process as the page and handler code. The advantage of using session state in process is that it’s very fast and convenient. However, it’s not durable. For example, if you restart Internet Information Services (IIS) or somehow knock the server down, all session state is lost. In some cases, this might not be a big deal. However, if the shopping cart contains sizable orders, losing that might be a big deal. In addition, the in-process session manager is confined to a single computer, meaning you can’t use it in a Web farm. (A Web farm is a group of servers tied together to serve Web pages as a single application.)

Store session state in a state server.      This option tells the ASP.NET runtime to direct all session management activities to a separate Windows Service process running on a particular computer. With this option, you have the advantage of running your server in a Web farm. The ASP.NET session state facilities support Web farms explicitly. To run in a Web farm, you direct all your applications to go to the same place to retrieve session information. The downside of this approach is that it does impede performance somewhat—applications need to make a network round-trip to the state server when loading or saving session information. To reduce the overall size of the stored information, when storing session data in the state server, with ASP.NET 4 you now have the option of using compression to reduce the amount of data being transferred. Just include the compressionEnabled=true setting in the sessionState section of web.config.

 Store session state in a database.  Configuring your application to use a SQL Server database for state management causes ASP.NET to store session information in a SQL Server database somewhere on your network. Use this option when you want to run your server from in a Web farm when you want session state to be durable and safe. As with the state server approach, when storing session data in the SQL Server database, you have the option of using compression to reduce the amount of data being transferred. Again just include the compressionEnabled=true setting in the sessionState section of web.config.

you might prefer to configure session state through the session state configuration page in IIS:

Session State Timeouts

The timeout configuration setting manages the lifetime of the session. The lifetime of the session is the length of time in minutes a session can remain idle before ASP.NET abandons it and renders the session ID invalid. The maximum value is 525,601 minutes (one year), and the default is 20.