Introduction
HTTP is a stateless protocol, meaning that a Web server treats each HTTP request for a page as an independent request; the server retains no knowledge of variable values used during previous requests.
What's a Session?
A session is a time limited, user (browser) specific, logical connection to a web application.
In other words, a server may treat subsequent requests, made from a specific browser/user, to web pages of the same web application, as logically placed under the same umbrella (session).
This way user specific variables or properly called Session specific variables can be stored somewhere, to be available for subsequent requests.
How requests can be identified to belong to a specific session?
When a user starts a new session, or the browser sends the first request to the web application, ASP.NET starts a new session and the SessionID for that session is sent to the browser with the response.
Then the ASP.NET would expect the SessionID to be sent back from the browser in the subsequent requests, to tie them all under the same session.
A session is considered active as long as requests continue to be made with the same SessionID value. If the time between requests for a particular session exceeds the specified time-out value in minutes, then the session is considered expired. Requests made with an expired SessionID value result in a new session being started.
How is the SessionID maintained?
That's configurable in the web application, Session ID values are transmitted between the browser and the Web server in a cookie, or in the URL if cookieless sessions are specified, as shown in the following example.
http://www.anysite.com/s(lit3py55t21z5v55vlm25s55)/orderform.aspx
For the first option, it won't work if the user disables cookies in his browser.
For the second option, session will be lost if the user re-writes the URL, removing the SessionID.
Where is the Session State stored?
That's configurable in the web application too.
If enabled, Session State or Session Specific variables can be stored in the following locations:
- InProc: stores values in the memory of the ASP.NET worker process. It offers the fastest access to these values. However, the session data is lost when the ASP.NET worker process recycles or the IIS is restarted.
It's not appropriate for Server Farms, where more than one web server is used, since subsequent requests can be directed to different servers.
- StateServer: uses a stand-alone Microsoft Windows service (aspnet_state.exe) to store serialized session variables. This service may run on another machine, thus be shared among multiple web servers in a web farm.
This is somehow slower than the InProc mode, due to serialization and deserialization. Especially if run on a separate machine.
- SQLServer: although this is the slowest solution of all, this is used for highest reliability, since a failover clustering can be used. Serialization is used here as in the StateServer mode.
- Custom: stores session state data using a custom session state store provider. You must specify the type of the session state store provider using the providers sub-element of the sessionState configuration element. See Implementing a Session-State Store Provider for more details.
For Out-Of-Proc options (anything but the InProc):
- Make sure session variables are serializable. See KB 312112 for details.
- Using a web farm, the Application Path of the website (For example \LM\W3SVC\2) in the IIS Metabase should be identical in all the web servers in the web farm. See KB 325056 for details.
The following is an example of the configuration section written under [system.web] section:
[sessionState mode="InProc" stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data source=127.0.0.1;user id=[username];password=[strong password]" cookieless="false" timeout="20" /]
More on using the SQL Server option:
To install the session state database on SQL Server, run the Aspnet_regsql.exe tool located in the following folder on your web server:
[systemroot]\Microsoft.NET\Framework\versionNumber
Supply the following information with the command:
-The name of the SQL Server instance, using the -S option.
-The logon credentials for an account that has permission to create a database on SQL Server. Use the -E option to use the currently logged-on user, or use the -U option to specify a user ID along with the -P option to specify a password.
-The -ssadd command-line option to add the session state database
The Aspnet_regsql.exe tool will create a database named ASPState containing stored procedures called from the ASP.NET to save and retrieve session state to and from the database.
Session data itself is stored in the tempdb database by default, which might not be the best option, since tempdb is cleared when the SQL Server restarts.
You can optionally use the -sstype option to change the storage location of session data.
The following are the possible values of the -sstype option:
t data will be stored in the SQL Server tempdb database.
p data will be stored in the ASPState database instead of in the tempdb database.
c Stores session data in a custom database. You must also include the name of the custom database using the -d option.
For example, the following command creates a database named ASPState on a SQL Server instance named "SampleSqlServer" and specifies that session data is also stored in the ASPState database: aspnet_regsql.exe -S SampleSqlServer -E -ssadd -sstype p
P.S. this turned out to be anything but a brief article, isn't it?
References:
.NET Framework Developer's Guide: Session State
ASP.NET: Session State Overview
Nothin' but ASP.NET: ASP.NET Session State
ASP.NET: Session-State Modes
.NET Framework General Reference: sessionState
INFO: ASP.NET State Management Overview
Peter A. Bromberg: ASP.NET Session State FAQ
ASP.NET Technical Articles: Session State Providers
ASP.NET: Securing Session State
No comments:
Post a Comment