ASP.NET.in.a.Nutshell.Second.Edition [Electronic resources] نسخه متنی

19.1 Comments/Troubleshooting

Understanding both the scope and the lifetime of the Session
collection for a given user is important when using the Session
object. As mentioned above, a new session is created when a user
first requests a page within an ASP.NET application for which session
state is enabled (session state is enabled by default in in-process
mode) and that stores a value in the Session collection. The boundary
of that ASP.NET application is defined by the boundary of an IIS
application. That is, the boundary of the ASP.NET session includes
all ASP.NET pages within a single IIS application and all of its
subfolders and virtual directories. It does not, however, include
subfolders that are defined as IIS applications. Figure 19-1 illustrates the different folder types in IIS.
In Figure 19-1, the

SessionWrite.aspx file writes a value to the
Session collection. Because the folder containing

SessionWrite.aspx is a virtual directory that is
a part of the

Chapter_19 application folder and
is not defined as its own folder, the session value written by

SessionWrite.aspx will be available to any page
in either the

Chapter_19 folder or the

SubApp subfolder. If, however, the

SubApp folder is configured as an IIS
Application (by accessing the Virtual Directory tab of the Properties
dialog for the folder and clicking the Create button in the
Application Settings section), it will then define its own session
boundaries, which will not be shared with the parent

Chapter_19 application.

Figure 19-1. IIS folder types

The lifetime of an ASP.NET session is set by default to 20 minutes
from the time of the last request to the application that created the
session, or until the Session.Abandon method is called.

Keep this lifetime in mind for two reasons:

• Any information that you store at the session level will continue to
  consume resources (memory, in the case of in-process or state service
  storage; memory and/or disk space, in the case of SQL Server state
  storage) for a minimum of 20 minutes (or whatever length
  you've set for the timeout value), and possibly
  longer depending on the user's activity in the
  application. For this reason, you should always carefully consider
  the potential costs associated with storing an item (particularly
  object instances) in the Session collection.

• If code in your page relies on an item being in the Session
  collection, your code could break if and when the session timeout
  value is exceeded. For this reason, you should always check to make
  sure that the item exists by testing whether the item evaluates to
  Nothing (or null in C#) before
  attempting to access the item's value.

In classic ASP, a big no-no was storing non-thread-safe COM objects
(i.e.,

any COM object written in Visual Basic)
in the Session collection. This was because such components would
force IIS to process requests only to the Session that stored the COM
object from the same thread that created the object, which could
limit scalability substantially. In ASP.NET, this is less of an
issue, since all managed .NET components can be stored safely in the
Session collection without the threading model impacting scalability.
The concerns about resource usage and scalability still apply,
however, so before storing objects in the Session collection,
carefully consider just how much memory will probably be consumed by
multiple serialized instances of the object being stored by multiple
sessions.

The difference between objects added to the Session collection and
objects created with Session scope using the
<object> tag in

global.asax is also important. While objects
added to the Session collection can be removed by using the Remove,
RemoveAll, or Clear methods, objects in the StaticObjects collection
(those created in

global.asax ) are not affected
by any of these methods.

In addition to properties and methods provided for backward
compatibility with classic ASP, the ASP.NET version of the Session
object also adds useful new properties and methods, including the
Count, IsCookieless, IsNewSession, and IsReadOnly properties, and the
Clear, CopyTo, and RemoveAt methods. The Count and CopyTo members are
derived from the ICollection interface, which is implemented by the
HttpSessionState class.

In this chapter, we'll use the following code
listing as the basis for most examples in the chapter. Unless
otherwise noted, each example will consist of the Page_Load event
handler for that particular example. Any displayed output messages or
return values will be shown as the Text property of the ASP.NET Label
named Message or by calling Response.Write.

<%@ Page Language="vb" %>
<html>
<head>
<script runat="server">
Sub Page_Load( )
'Example code will go here
End Sub
</script>
</head>
<body>
<asp:label id="Message" runat="server"/>
</body>
</html>