|
Manage Client State
Working with and understanding how client state is used in your app is critical to putting a good design into practice. Examine three techniques for managing client state.
by Matthew Gibbs and Rob Howard
November 8, 2004
Technology Toolbox: VB.NET, C#, SQL Server 2000, ASP.NET
Editor's Note: This article is excerpted from Chapter 5 of Matthew Gibbs' and Rob Howard's book, Microsoft ASP.NET Coding Strategies with the Microsoft ASP.NET Team [Microsoft Press, ISBN: 073561900X]. It has been edited for length and format to fit the magazine. You can read a PDF of the full chapter here.
Working with and understanding how client state is used in your application is critical to putting a good design into practice. In this article, we'll examine three techniques for managing client state: session state, view state, and cookies. The most common type of client state is session state.
ASP.NET session is free-threaded, but in some cases you can access it serially. Session state in ASP.NET still utilizes an HTTP cookie for managing the SessionID, but ASP.NET also supports storing the SessionID in the URL if using cookies is not desirable. ASP.NET session state also supports two out-of-process modes to simplify deployment in Web server farms: out-of-process state server (StateServer) and out-of-process SQL Server (SQLServer).
ASP.NET defaults to in-process (InProc) session state. When in this mode, values stored within session state don't require serialization support and are stored within the memory space of the ASP.NET worker process. This behavior is identical to the way ASP stores its session data. However, instead of the data being stored in the IIS process, the data is stored in managed memory within the ASP.NET worker process.
When stored in-process, session state data is lost whenever the process is recycled. In Windows Server 2003 running IIS 6, the worker process recycles automatically every 29 hours, which is the default setting and is configurable. However, this means that the session data will be lost every 29 hours, whether it's 2 a.m. or 3 p.m.
InProc is by far the fastest way to use session state. It doesn't support Web farm scenarios (unless you enforce client affinity), but it also doesn't have the serialization and deserialization overhead associated with out-of-process modes. It's safe to assume that out-of-process session state is 15 to 30 percent slower (depending upon variables such as network speed and the size of the object or objects being serialized).
Use in-process session state if you have only a single server. In IIS 6, either use out-of-process or disable process recycling behavior to avoid data loss. This code shows the configuration settings from machine.config that specify the default settings for session state:
<configuration>
<system.web>
<sessionState mode="InProc"
stateConnection
String="tcpip=127.0.0.1:42424"
stateNetworkTimeout="10"
sqlConnectionString="..."
cookieless="false"
timeout="20" />
</system.web>
</configuration>
The timeout value specifies the time, in minutes, after which a session is considered timed out and its values can be removed. Session state uses a sliding expiration: The timeout is reset each time the item is requested. A session could theoretically be kept alive indefinitely if a request was made just once before the value in the timeout is reached.
InProc session state allows any data type to be stored, and it participates in the global session events Session_OnStart, which is raised when a new session is created; and Session_OnEnd, which is raised when a session is abandoned. You can program these events in either global.asax or within an HTTP module. Don't use the Session_End event; it can be called only for sessions created in the InProc mode. The event is not raised for sessions created in one of the out-of-process modes when sessions are abandoned.
Back to top
|