19.1 CommentsTroubleshooting

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  runat="server"/> </body> </html>