The View State is saved in the session for each user. A session object is user specific and times out items when the user session times out. This timeout can be configured by changing the timeout parameter in your application’s Web.config file. Each session object is only accessible by the given user. The view state is saved in serialized form in the session state and must be de-serialized when retrieved.
Smaller page size: The amount of data transferred to each user is minimized since there is no View State that is sent back and forth. The size of the page is close to the size of the actual data on the page plus any HTML to enhance the appearance.
Faster: Because view state data is stored on the application sever and is not encrypted or sent to the client browser, this option results in the application running faster.
Missing data: Occasionally when users return back to a page after a long time and try to make further changes to the page like filtering by another value, they may see the new page with some data missing on the page. This is the result of the session expiring or being replaced with newer session data since there may not be sufficient memory to store all of the view state data for all sessions. In this case, you can increase the memory, increase the timeout or change the view state location to Page. Alternatively, use the Cache option and set the timeout to be file or event based.
Requires more memory: Since session data is stored in memory, your server requires additional memory to store all of the session data. When there is insufficient memory, the oldest session data is discarded in favor of the newer session data. This may result in View State not being available when the end user returns to the page.
Application recycling loses session state: If your application is recycled either by modifying its Web.config file, changing the DLLs or by recycling the process, the view state data stored in the session will be discarded. When an end user returns to the page expecting the view state to be available, they may encounter unexpected behavior.
Windows 2003: Microsoft IIS running under Microsoft Windows 2003 allows configuration options to recycle the ASP.NET worker process based on a variety of criteria such as memory usage or based on time elapsed since the last recycle.
Hosting: If you are hosting your application at a hosting site, you may not be able to control how much memory is allocated to your application. You may not be able to control the frequency with which the worker process is recycled.
.NET session data itself can be managed in three different ways:
InProc (default) - Stored in the ASP.NET Worker Process (aspnet_wp.exe) area. The session data is lost when the process or the application domain is recycled as explained above.
StateServer - Session state is stored in a separate process (aspnet_state.exe) which can be stored on a different system. Since it can be stored on a different system, this option can also work in a web farm scenario. The View State data must be serialized since the data storage is outside the process. Slower than InProc since data retrieval and saving requires more time.
SQLServer - Session state is stored in a SQL Server database. This option will also work in a web farm scenario. The View State data must be serialized since the data storage is outside the process. Slowest option of all three since the database overhead is added to storage and retrieval times. This is the same as option 5 of storing the session data in a database.
Modify the sessionState key in your application’s Web.config file to choose between InProc, StateServer or SQLServer.