Except from storing states on the client, you can also store state data on the server. It is a good practice to store very sensitive information, like bank information, on the server instead of the client. You might also have states that are application wide and not client specific that you need to store on the server.
In ASP.NET there is two ways of storing state on the server. There is application state and session state.
Application State
Application state information is is global to the application and is available to all pages, regardless of the identity of the client. It is a form of application-level caching of data that can be used for every request. Application data is stored in an instance of the HttpApplicationState class that is provided through the Page.Application property. This class is a key-value dictionary, where each value is stored and accessed by its key. You can add and read from the application state from any page on the server.
Data stored in the Application object is not permanent; it will be lost any time the application is restarted. In particular, IIS might restart you ASP.NET application at any point. To read an write values to the Application object you can do the following.
Because the Application object is not thread-safe, you need to lock it when writing data to it. In the example above it is not that important but imagine if you have a visitors counter that adds and remove visitor count. Then if it is not Locked/Unlocked you might end up with a incorrect number of visitors.
Application Events
Application events can be used to handle events raised by the Application, the most common events are Application_Start, Application_End and Application_Error.
- Application_Start This event is raised every time the application is started.
- Application_End This event is raised every time the application ends.
- Application_Error This event is raised when there is an unhandled error propagating up to the application-level.
Session State
Session state is a user-specific state that is stored by the server. It is available only to pages accessed by a single user during a visit to you site. It is very similar to use as the Application state, but it the data is unique to the user. Session state is lost if the user ends hos or her session (or time out).
Reading and Writing Session Data
You read and write data the Session object the same way you would to for the Application object. The Session object is a an instance of the HttpSessionState class and represents a key-value dictionary collection. The following examples shows how.
Unlike the application there is no need to lock the Session object because it is user-specific and the value is only changed for the current user making the request.
ASP.NET writes a cookie to the client to keep track of the session. This cookie is called ASP.NET_SessionId and contains a random 24-byte value. Requests made by the client submits this cookie to the server and ASP.NET maps the cookie’s value to the session on the server. However if the client browser do not support cookies, or have it turned off, ASP.NET allows you to enable cookieless session state.
Without cookies ASP.NET tracks sessions by using the URL, embedding the session ID in the URL after the application name and before any remaining file or virtual directory identifier. For example.
This behavior can be configured by using the SessionState element in the web.config.
You can also disable session state entirely by setting mode=”off” in the SessionState configuration.
If you want to disable session state for a specific page you can use the EnableSessionState in the @ page directive on the page.
Session Events
The Session object have two events that can be handled by the developer. This two are Session_Start and Session_End. Like Application events they you handle them by creating methods in the Global.asax file.
- Session_Start Raised when a new user requests a page on you site and thus begins a new session.
- Session_End Raised when a session is abandoned or expires. This event can be used to log information or free per-session resources. This event is only raised when using the InProc session mode, more on that later.
The following shows an example of using the Session events.
Storing Session State
ASP.NET provides five ways of storing the session state on the server-side.
- InProc Stores session states in memory on the web server. This is the default mode. It offers much better performans then the other two but is limited to only using one server. So you can not use this in a web farm.
- StateServer Stores session in a service called the ASP.NET State Service. This ensures that session state is preserved if the web application is restarted and also makes session state available to multiple servers in a web farm. When configuring Session state mode to StateServer, remember to always set the ASP.NET State Service to startup type Automatic.
- SQLServer Stores session state in a SQL Server database. This ensures that session state is preserved if the web application is restarted and also makes session state available to multiple servers in a web farm. You will want to performance-test when using SQLServer mode.
- Custom Enables you to specify a custom session stage storage provider. You also need to implement the custom storage provider.
- Off Disables session state.
Configuring Session State Modes
You can configure the Session state mode in the sessionState element in your application’s web.config file. The following example shows the session state stored in a SQL server.
To use the SQLServer mode you need to create the ASPState database on the SQL server. To do this run the following command.
aspnet_regsql.exe -ssadd -sstype p -E
Then you have a new database in you SQL server.
Now the sessions state will be stored in the dbo.ASPStateTempSessions table.
