Session in Web Form

Pros:

• If you have a variable that needs to be passed around to a lot of web pages, it may simplify things to use a Session variable, rather than passing the variable around through the QueryString.
• Session variables allow for customization of a web site. Each visitor to your site can have a customized experience. While this is true, it is also true that with the advent of LDAP and items such as MS Site Server and the like, it is no longer necessary to put all of your customization that is dependent upon user preference into session variables.
• Session variables take you one step closer to VB programming in the sense that you can grab one without initializing the variable, use it whenever you want to, and not have to worry about releasing it when you've finished using it.

Cons:

• Session variables and cookies are synonymous. So if a user has set his browser not to accept any cookies, your Session variables won't work for that particular web surfer!
• An instance of each session variable is created when a user visits the page, and these variables persist for 20 minutes AFTER the user leaves the page! (Actually, these variables persist until they "timeout". This timeout length is set by the web server administrator. I have seen sites that the variables will collapse in as little as 3 minutes, and others that persist for 10, and still others that persist for the default 20 minutes. ) So, if you put any large objects in the Session (such as ADO recordsets, connections, etc.), you are asking for serious trouble! As the number of visitors increase, your server will experience dramatic performance woes by placing large objects in the Session! 
• Since Session variables can be created on the fly, used whenever, and do not require the developer to dispose of them explicitly, the overuse of Session variables can lead to very unreadable and unmaintainable code.
• Session variables take you one step closer to VB programming in the sense that you can grab one without initializing the variable, use it whenever you want to, and not have to worry about releasing it when you've finished using it.

Hi Aamir,


ASP.NET session caches per user session state.It basically uses "HttpSessionState" class.

Following are the limitations in classic ASP sessions :-

ASP session state is dependent on IIS process very heavily.So if IIS restarts
ASP session variables are also recycled.ASP.NET session can be independent
of the hosting environment thus ASP.NET session can maintained even if IIS
reboots.
 ASP session state has no inherent solution to work with Web Farms.ASP.NET
session can be stored in state server and SQL SERVER which can support
multiple server.
 ASP session only functions when browser supports cookies.ASP.NET session
can be used with browser side cookies or independent of it.


Please refer the below link

http://asp.net-tutorials.com/state/sessions/




Thanks

Hi
   Session:-
        In classic ASP, the Session object was held in process (as was everything) to the IIS process and therefore any crash to the IIS or apps pool being reset will cause the whole Session object being resetted. Hence this will make the Session objects not reliable at all and cannot be used to stored important data especially if your website is dealing with client login information or e-commerce type of website. In ASP.NET 2.0, new features has been introduced to make the Session objects more reliable and robust.
       ASP.NET session state enables you to store and retrieve values for a user as the user navigates the different ASP.NET pages that make up a Web application. HTTP is a stateless protocol, meaning that your Web server treats each HTTP request for a page as an independent request; by default, the server retains no knowledge of variable values used during previous requests. As a result, building Web applications that need to maintain some cross-request state information (applications that implement shopping carts, data scrolling, and so on) can be a challenge. ASP.NET session state identifies requests received from the same browser during a limited period of time as a session, and provides the ability to persist variable values for the duration of that session.



Main Contents
There are three types of storage providers for ASP.NET 2.0 as opposed to 1 provider in classic ASP Session object.
1. In Process Session State store (Stores sessions in ASP.NET memory cache--> Used in Classic ASP)
2. State Server Session State Store (Stores sessions in the ASP.NET State Server service).
3. Sql Session State Store (Stores sessions in Microsoft SQL Server Database and is configured with aspnet_regsql.exe).

To change the different provider of session state, you need to edit your web.config file.







Code Samples for Storing Data in Session objects
1. Storing String in Session Objects
Session["MyData"] = TextBox1.Text;

2. Storing Objects in Session Objects
Client oClient = new Client();
Session["MyData"] = oClient;

Code Samples for Retrieving Data in Session Objects
1. Retrieving String in Session Objects.
TextBox1.Text = Session["MyData"].ToString();


2. Retrieving Objects in Session Objects
Client oClient = (Client)Session["MyData"];

//-------------------------------------------
For more detail refer this best article....
http://www.codeproject.com/KB/session/ExploringSession.aspx#2

http://msdn.microsoft.com/en-us/library/ms178581.aspx