Session State Advantages & Disadvantages

ASP.NET Session State is improved in many ways when compared to sessions in classic ASP. In classic ASP, only place where session could be stored is in application's process. Since web server's memory is finite, high traffic website which uses session intensively would soon run out of memory, and therefore start paging to disc which dramatically decreases performances. This scalability problem is so significant that using of sessions in classic ASP is considered like bad coding habit. There are some other drawbacks too, session state in ASP 3.0 is unreliable, doesn't work if client is disabled cookies, doesn't support web farms etc.

ASP.NET Session State solves all of these problems. For smaller websites, you still can use InProc mode, which is equivalent for how sessions work in classic ASP. In addition to InProc mode, ASP.NET Session State supports StateServer, SQLServer and Custom modes which store session out of process, on same or dedicated server. Using of dedicated State Server or SQL Server increase scalability since web server's memory remains free. State Server and SQL Server supports web farms and web gardens. Also, session data survive if ASP.NET process restarts, work on clients which don't support cookies etc. Unlike classic ASP where sessions are considered useless for storing anything larger of few integer variables, we can say that ASP.NET Session State is useful method that can and should be used in appropriate scenarios.

Of course, ASP.NET Session State is not solution for every problem. Sessions  have their own advantages and disadvantages. Here are short review of advantages and disadvantages of ASP:NET sessions in general, and also specific benefits of each session state mode.

ASP.NET Session State advantages

- Sessions are very simple to use. If you have a global variable related to individual visitor, you can place it in session and it will be visible from all pages on website.
- If InProc mode is used, any type of object could be stored. In case that Session State or SQL Server is used, objects must be serialized before saving.
- Separated global data for each visitor. Every visitor has its own collection of session variables.

ASP.NET Session State disadvantages

- Every variable is stored as Object. That means you need to convert Object to certain type when read session variable.
- In addition to this, if session is empty, Object will be null. Before reading session variable, you need to check it for null. Even if variable is initialized before, it could be null because session is expired. An attempt to use null session value could return an exception. If value of session variable is null, common practice is to use some default value instead of meaningless null. If value is not null, you must convert it to appropriate type because all session variables are type of object. When do all this things, you should pay attention to avoid hard coding. More about reading and writing of session variables on scalable and maintainable way you can read in How To Write, Read and Delete Session State Variables tutorial.
- Variable name is type of string. If you hard code name of the variable, there is an option to make type mistake somewhere. The problem is, if you try to read session variable that doesn't exist, ASP.NET will not return any exception or warning. It will simply create new variable with wrong name which has null value. These types of errors could be hard to find.
- Session data should not be used for storing of sensitive data. There is a possibility that malicious user obtain regular visitor's session id. If session state is used to store information like: "allow access to administration area or not" or something like that, attacker could see website's sensitive data, other's private data, edit database, delete content etc.
- If InProc mode is used, sessions easily exhaust all server resources and thus decrease website performances.

Advantages/Disadvantages of different ASP.NET session modes

ASP.NET Session State supports four different modes. Each mode has its own advantages and disadvantages. Which one you should use, depends of your web application requirements. Here is a short comparation of each mode. More about different ASP.NET Session State modes and how to implement them you can read in ASP.NET Session State Modes Explained tutorial.

InProc mode advantages

InProc is the easiest option. Inproc mode works by default, so it doesn't require any configuration. Just use it.

InProc mode is also fastest option. Session data are stored in web server's memory, in application's process.

You can place any .Net data type in session. Other modes require object to be serializable.

InProc mode disadvantages

Because session data are stored in memory, on higher traffic web sites sessions could overburden web server. When there is no enough physical memory, Windows will start use hard disc for paging which dramatically decreases performances. InProc mode is not scalable option.

Session data are deleted whenever ASP.NET application restarts or get recycled. If occurs frequently, this could be very annoying because it looks like sessions simply don't work. More about when this could happen see in Restart and Stop of ASP.NET Application tutorial.

InProc doesn't support websites hosted on multiple processors (web gardens) or multiple servers (web farms).

If you place non serializable classes in sessions, it is hard to change session mode later. Storing any type of object is certainly advantage of InProc. But, it is also disadvantage if you plan to switch to State Server or SQL Server later. Since State Server and SQL Server demand serialiazable objects, you can't change mode until you make all classes serializable. On large existing application, this could be a big task. If there is any chance to change session mode later, better use only serializable classes from the beginning of project.

StateServer mode advantages

Big improvement of State Server, when compared to InProc mode, is that sessions' data survive if ASP.NET application restarts. State Server use different working process, so if ASP.NET process restarts, that doesn't affect State Server and session variables remain intact.

If dedicated State Server is used, session data are stored on other computer. In this case web server's memory remains free, so web application executes faster.

State Server supports web gardens and web farms.

StateServer mode disadvantages

State Server requires additional configuration, and in case of dedicated State Server, one more machine to obtain and maintain.

State Server is usually not allowed by shared web hosting providers. If you use shared web hosting, you probably have not access to State Server.

If State Server is restarted, session data are lost.

State Server is slower than InProc mode.

SQLServer mode advantages

SQL Server is most reliable of all modes. Session data are intact if ASP.NET restarts, but also if SQL Server restarts.

SQL Server is also most scalable option.

SQL Server is often available in shared hosting scenario.

SQLServer mode disadvantages

It requires most configuration.

If you already don't use SQL Server on database driven website, it will require additional cost to obtain license.

SQL Server is slowest of all options.

Custom mode advantages

You have complete control over sessions. It is possible to create even custom session id.

You can support different data sources. That could be useful to store session data on other database, like Oracle, MySQL, MS Access etc.

Custom mode disadvantages

It requires most work. Custom session state provider is doable task, but takes significant time and it's not kind of task for beginners. As alternative, you can try to find some third party free or commercial session state provider which works with your specific data source.

Conclusion

ASP.NET Session State is useful method to keep data specific for individual visitor. Session data are lost when session expires. Their purpose is just to save data during single visit. This could be a problem if visitor is not finished visit, but just working on something else. In that case, when visitor returns to continue work on your website, session data will be deleted. This could be solved by increasing of session timeout or maintaining session alive with client side code. More about how to do this, you can find in How To Keep ASP.NET Session Alive tutorial.

In case that data should remain between visits for a longer time, better use some other method, like Profile class, cookies, store data to database etc. More about different options for state management that could be used instead of Session State you can read in ASP.NET Session State Alternatives tutorial.

Happy coding!

Tutorial toolbar:  Tell A Friend  |  Add to favorites  |  Feedback  |   Google