InProc Mode in ASP.NET Session State

ASP.NET Session State offers four modes to specify where you can store session data. By default, ASP.NET uses InProc mode. In this case, session data are stored inside of working process, in web server's memory. Because of that, InProc mode is fastest of all possible options. Other possible options are StateServer, SQLServer and Custom. State Server uses Windows service to store sessions' data. More about using State Server as sessions storage you can find in How to Store Session Data in ASP.NET State Server tutorial.

One more option is to use SQL Server database as storage. More about this you can read in How to store ASP.NET session state on SQL Server tutorial. At last, Custom mode enables you to build your own Session State provider. In this case, all depends on you. You can even create your own Session IDs. Example use of Custom mode could be to implement storage on some other database, like MySQL or Oracle.

InProc mode advantages

InProc is default mode which works without any configuration. It is easiest option to implement because you don't need to configure anything. Just read and write session variables in code. Other modes, like SQLServer or StateServer modes require additional configuration.

One more advantage of InProc mode is that you can put anything in session variables. State Server or SQL Server requires objects to be serializable. But, if you use InProc, you can save any object in session variable even if it is not serializable.

InProc mode works on shared web hosting. State Server is usually not allowed, and some shared web hosting providers give option to use SQL Server. In the other hand, InProc works in any hosting package.

InProc mode disadvantages

Reliability is first problem when using InProc. When using InProc mode, all sessions are lost whenever web application restarts. Restart could happen very frequently because of numerous reasons (see Restart and Stop of ASP.NET Application tutorial) so InProc mode is not enough reliable in many scenarios. If you change web.config, Global.asax, any file inside App_Code folder, change anything in /bin folder etc., ASP.NET application will restart. Also, application will restart if too much memory is used, certain number of compilation is reached etc.

If InProc is used, each time web application restarts or get recycled, all session variables will be deleted. This could harm user's experience. If user was in the middle of long task, losing of session means that he or she must start from the beginning.

Scalability is one more problem when using InProc mode. Each user has its own collection of session variables. On high traffic websites, with thousands of visitors online, sesssion data easily grow and spend complete memory on web server. When there is not enough physical memory, Windows will start paging on disc which slows down application and decreases performances.

This could happen even on small traffic websites, if large objects are stored in sessions (e.g. data tables) or session timeout is increased a lot (in this case, Session State keeps data of many inactive visitors).

There is a problem on web farms and web gardens. If you host website on web farm (multiple servers) or web garden (multiple processors) ASP.NET application will use multiple processes. Since InProc stores session data inside single process, session data will be lost when visitor request goes to different server or processor and will be readable again if request goes to process where session is written. You can't know if next request will be directed to same process or not. This kind of error could be very confusing since sessions disappear and get back on every refresh :). Possible solution could be to use load balancing to direct every request from one user to same server (e.g. based on visitor's IP address).

But, since websites on web farms are usually large sites with a lot of traffic, they also experience previous problems with reliability and scalability. So, better option is to simply move to State Server or SQL Server mode. State Server and SQL Server store sessions outside of ASP.NET process and therefore sessions' variables are accessible from any server in server farm, or any processor in web garden. You can add additional servers or processors when needed.

Serialization/Deserialization is potential problem. InProc doesn't require serialization of complex objects. This is basically advantage, but in practice could be big problem when you least expect. Since InProc allows to put anything in session, you could end up with many non-serializable objects in session. If you need to switch to Session State or SQL Server later (e.g. your website became popular and now you have many visitors), you can't because stored classes are not serializable. Suddenly something that looks like advantage becomes a problem and you must change all problematic objects at once.

So, good practice is to avoid storing of non serializable classes in Session State. On this way, you can change session mode any time if needed. When you developing new application you can use State Server from the beginning, to be sure that all objects in session are serializable.

Conclusion

In classic ASP, only option to store session data was inside of process. In ASP.NET, InProc mode represents counterpart of old ASP 3.0 sessions. ASP.NET Session State is improved and now offers two new out-of-process modes: State Server and SQL Server. These modes are designed to solve well known InProc problems with scalability and reliability.

Many websites still uses InProc because it works by default and doesn't require any configuration. It is also fastest option. If web site has low traffic and ASP.NET files are not changed often (e.g. you just use complete application, like forum or blog, and add new content through it) you could be happy with InProc mode.

Every more demanding case, where ASP.NET application restarts because of some file change or high memory consumption, will make InProc useless. Every time application is restarted, session data will be deleted. Fortunately, they are more reliable StateServer and SQLServer modes. In some scenarios, even improved ASP.NET Session State can't satisfy project requirements. More about other possible options you can find in ASP.NET Session State Alternatives tutorial.

Happy coding!

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