State – Part 2 (Session State)
September 29, 2010 § 1 Comment
So, we’ve already discussed View State; let’s continue with a discussion of Session State. While discussing View State, we talked about the fact that View State is stored in hidden fields within the HTML page, and this has both positive and negative effects.
Objects in Session are good for the life of the session, rather than the life of the page (as they are with View State). This is an important distinction, and often drives the decision to use either View State or Session state.
Session objects are stored server side on a per-user basis. Typically, the session is stored In-Process (or within the ASP.NET worker process – either aspnet_wp.exe or w3wp.exe, depending on which version of IIS you are using). There are multiple options for storing Session besides In-Process, but that discussion is an entire post in and of itself.
So to start with, how does session work? Well, assuming your application has Session State enabled (which is the default, although you can disable it), a session id is automatically generated when the user first accesses the site, and that session id is transmitted between the client and the server on every request/response. That session id is also tied to a server-side hashtable, which can be accessed with the Session object.
This has some similarities with the technique that we discussed when talking about View State, wherein you transmit a small identifier between the client and server, and fetch the object from (or save the object to) the database for storage. Using Session streamlines the process, and yields some architectural and performance advantages over that technique. For instance, this pattern using Session State is perfectly acceptable and performant because only the session id is transmitted to and from the client while the actual object remains on the server.
public partial class Example : System.Web.UI.Page
public Customer Customer
Session["Customer"] = value;
|The session id can be transmitted to and from the client in one of two ways. You can either transmit the session id using a cookie (which is the default), or you can opt not to use a cookie. There really isn’t a significant difference between the two techniques. With the first, the session id is in a cookie, which is invisible (mostly) to the user. With the second, the session id is injected into the url, which is visible to the user. So, if we navigate Firefox to Visual Studio Magazine, for instance, we can view the individual cookies, and see something like this:|
The cookieless version can be preferable, as it is possible to deny cookies with a browser setting, effectively making your site unusable for anyone that does have cookies disabled in their browser. In order to switch to the cookieless version, you simply need to modify your web.config file.
There are, of course, some potential issues with using session state, particularly when in a web garden or web farm environment. In the next article in this series, we’ll discuss this problem further and some ways to mitigate or eliminate those issues.