Session State
ASP.NET provides the cross-request state information (shopping carts, data scrolling, and so on) infrastructure that Web applications require, with built-in session-state functionality that enables you to take the following actions:
Automatically identify and classify requests coming from a single browser client into a logical application session on the server.
Store session-scoped data on the server for use across multiple browser requests.
Raise appropriate session-lifetime management events (Session_OnStart, Session_OnEnd, and so on) that can be handled in application code.
Note The Session_OnEnd event is supported only the in-process session-state mode. This event is not raised if you use State Server or SQL Server modes.
Automatically release session data if the browser does not revisit an application within a specified time-out period.
This topic provides an overview of session state, describes how active ASP.NET sessions are identified and tracked, explains the session-state store and general structure, and concludes with a high-level code example.
Session State Overview
HTTP is a stateless protocol, which means that it does not automatically indicate whether a sequence of requests is all from the same client or even whether a single browser instance is still actively viewing a page or site. As a result, building Web applications that need to maintain some cross-request state information (shopping carts, data scrolling, and so on) can be extremely challenging without additional infrastructure help.
ASP.NET provides the following support for sessions:
A session-state facility that is easy to use, familiar to ASP developers, and consistent with other .NET Framework APIs.
A reliable session-state facility that can survive Internet Information Services (IIS) restarts and worker-process restarts without losing session data.
A scalable session-state facility that can be used in both Web farm (multicomputer) and Web garden (multiprocess) scenarios and that enables administrators to allocate more processors to a Web application to improve its scalability.
A session-state facility that works with browsers that do not support HTTP cookies.
A throughput equivalent to that of ASP (or better) for core session-state scenarios (50/50 read/write when putting items into shopping carts, modifying last page visited, validating credit card details, and so on).
Session state, however, does not persist across Web application boundaries. If a Web application switches to another application during execution, the session information is not available to the new application.
Identifying a Session
Each active ASP.NET session is identified and tracked using a 120-bit SessionID string containing only the ASCII characters that are allowed in URLs. SessionID values are generated using an algorithm that guarantees uniqueness so that sessions do not collide, and randomness so that a malicious user cannot use a new SessionID to calculate the SessionID of an existing session.
The SessionID strings are communicated across client-server requests either by means of an HTTP cookie or a modified URL with the SessionID string embedded, depending on how you configure the application settings.
Session-State Store
ASP.NET provides a simple and easy-to-use session-state model that you can use to store arbitrary data and objects across multiple Web requests. It accomplishes this using a dictionary-based, in-memory cache of object references that live within the IIS process. When using the in-process session-state mode consider the following limitations:
When using the in-process session-state mode, session-state data is lost if aspnet_wp.exe or the application domain restarts. These restarts commonly occur in the following circumstances:
Setting an attribute in the
The Global.asax or Web.config file is modified.
Changes to the \Bin directory of the Web application.
Antivirus software scans and modifies the Global.asax file, the Web.config file, or a file in the \Bin directory of the Web application.
If you enable Web garden mode in the
Instead of keeping live objects, the .NET State Server simply stores session state in memory when in out-of-proc mode. In this mode the worker process talks directly to the State Server. In SQL mode, session states are stored in a SQL Server database and the worker process talks directly to SQL. The ASP.NET worker processes are then able to take advantage of this simple storage service by serializing and saving (using .NET serialization services) all objects within a client's Session collection at the end of each Web request. When the client revisits the server, the relevant ASP.NET worker process retrieves these objects from the State Server as binary streams, deserializes them into live instances, and places them back into a new Session collection object exposed to the request handler.
In SQL mode, session state can also be configured to work in a failover cluster. A failover cluster is two or more identical, redundant Web servers that store their session data on a separate computer in a SQL Server database. For information on how to set up this configuration, see Configuring SQL Server Mode.
By cleanly separating the storage of session data from the application's use of it, ASP.NET supports several powerful scenarios that were unavailable with earlier versions of ASP:
Recovery from application crashes, because the memory used for session state is not within the ASP.NET worker process.
Because all state is stored separately from an individual worker process, it is not lost if the process crashes due to an access violation or is forcibly restarted by the IIS Admin Service in the event of a deadlock or memory leak.
Partitioning an application across multiple worker processes.
Because all state is stored separately from worker processes, you can cleanly partition an application across multiple processes. Such partitioning can dramatically improve both the availability and the scalability of an application on multiple-process computers. Moreover, because it associates each worker process with a single computer, ASP.NET is able to eliminate cross-processor lock contention, one of the major scalability bottlenecks in earlier versions of ASP.
Partitioning an application across multiple Web farm computers.
Because all state is stored separately from worker processes, you can partition an application across multiple worker processes running on multiple computers. The model for communicating state between a worker process and a state service running on different computers is almost the same as that for processes and servers running on the same computer. In either case there can only be one State Server per Web farm.
Session State Structure
ASP.NET-based applications use an event-based execution organization to enable multiple .NET Framework class modules to participate in the processing of a single Web request.
The SessionState Module
The .NET Framework implements session state through the SessionStateModule class (derived from IHttpModule), which participates in the execution of each request received by a .NET-based application. The SessionStateModule is responsible for either generating or obtaining unique SessionID strings and for storing and retrieving state data from an external state provider.
Session State Collections
The SessionState class exposes two state collections: Contents and StaticObjects. The Contents collection exposes all variable items that have been added to the session-state collection directly through code. For example:
[Visual Basic] Copy Code ' Visual Basic code from within a page, a handler, or Global.asax.
Session("Message") = "MyMsg"
Session("AppStartTime") = Now
[C#]
// C# code from within a page, a handler, or Global.asax.
Session["Message"] = "MyMsg";
Session["AppStartTime"] = DateTime.Now;For compatibility with earlier versions of ASP, these values also can be accessed through a Contents property on the application object, as in the following example.
[Visual Basic] Copy Code ' Visual Basic code from within a page, a handler, or Global.asax.
Session.Contents("Message") = "MyMsg"
Session.Contents("AppStartTime") = Now
[C#]
// C# code from within a page, a handler, or Global.asax.
Session.Contents["Message"] = "MyMsg";
Session.Contents["AppStartTime"] = DateTime.Now;The StaticObjects collection exposes all variable items that have been added to the session-state collection through
0 Response to "Session State Managemnet"
Post a Comment