When you think ASP, think...
Recent Articles
All Articles
ASP.NET Articles
ASPFAQs.com
Message Board
Related Web Technologies
User Tips!
Coding Tips

Sections:
Sample Chapters
Commonly Asked Message Board Questions
JavaScript Tutorials
MSDN Communities Hub
Official Docs
Security
Stump the SQL Guru!
XML Info
Information:
Feedback
Author an Article
ASP ASP.NET ASP FAQs Message Board Feedback
Print this page.
Teach Yourself Active Server Pages in 21 Days!
Teach Yourself Active Server Pages 3.0 in 21 Days


Summary
Today we examined a number of approaches to maintaining state. We looked at how to use the querystring to pass state information around from one page to another via hyperlinks. We also looked at using cookies to persist state. The bulk of the day, though, concentrated on using the Session and Application objects.

The Session object is a built-in ASP object designed to persist user-specific information. New visitors are granted their own Sessions, which serve as warehouses for session variables. These session variables are bits of personalized information, different for each user. Because a Session object instance exists for each user, it is important to use session variables sparingly. The more session variables used, the more memory consumed by each Session object instance. If your site has many concurrent users, such memory consumption may affect the Web server's performance.

The Application object is another intrinsic ASP object. The purpose of the Application object, however, is to maintain Web site-specific information. Only one instance of the Application object exists for the entire Web application. Each client accesses this one instance when retrieving or setting Application information. Because multiple users can modify application variables at the same time, it is important to Lock the Application object before modifying any application variables. After you have made your updates to the application variables, be sure to UnLock the Application object.

Finally, we discussed how to initialize your application and session variables using the OnStart event handler of the Application and Session objects. The Session and Application objects have one other event as well, the OnEnd event, which should be used to explicitly free any session or application level objects. The event handlers for both the Application and Session objects need to be placed in a file in the Web's root directory named Global.asa. Placing these event handlers here ensures that they will be executed when the OnStart and OnEnd events fire.

Tomorrow we will examine some standard ASP components. These components, written by Microsoft, provide some powerful functionality and can help make your Web site easier to manage and update. We will also talk briefly about the built-in Server object and how it is used to instantiate objects.

Q&A

    Q Do I need to have a Global.asa even if I don't need event handlers for OnStart and OnEnd?
    A If you plan on using session or application variables at all on your site, you should have a Global.asa. The OnStart event for the Application and Session objects should be used to initialize your session and application variables. If, for some reason, you want to use session or application variables on your site but do not want to initialize them in the OnStart event handler, you should still create a blank Global.asa file. A blank Global.asa file contains the four event handlers but places no code inside these event handlers. Here is an example of a blank Global.asa file:

    <SCRIPT LANGUAGE=vbscript RUNAT=SERVER>
    Sub Application_OnStart()
    End Sub
    
    Sub Application_OnEnd()
    End Sub
    
    
    Sub Session_OnStart()
    End Sub
    
    Sub Session_OnEnd()
    End Sub
    </SCRIPT>
    

    If you plan on using session or application variables on your Web site, always have a Global.asa file in your Web's root directory. If you don't want to write any event handlers for the Application or Session objects' OnStart or OnEnd events, simply use a blank Global.asa.

    Q When initializing application variables in the OnStart event of the Application object, do I need to first Lock and then UnLock the Application object?
    A Whenever you alter the contents of an application variable in an ASP page, it is important to use the Lock and UnLock methods of the Application object. However, Locking and UnLocking in the Application object's OnStart event is not necessary. Why is it important to Lock and UnLock on ASP pages but not in the Application's OnStart event?

    With ASP pages, because every user accesses the same instance of the Application object, when one user changes an application variable's value, the change affects all other users. Because multiple users may be trying to update the same application variable simultaneously, to prevent the application variable data from being corrupted, it is important to Lock the Application object before altering a variable. When finished, UnLock the Application object. This will allow the next user to alter an application variable.

    The Application object's OnStart event, however, only fires once, when the first instance of the Session object is created. Because this only happens once, when the first user is visiting since the Web server was last restarted, there are no concurrency issues. Therefore, using the Lock and UnLock methods in the OnStart event of the Application object is unneeded.

    Q What method of state maintenance is best?
    A This depends on a number of factors. Because performance is important on a Web server, you want to make sure that you choose a state maintenance method that will not greatly impair the performance of your Web site. The use of session variables can lead to serious performance degradation if they are not properly used. First and foremost, it is vitally important not to place objects into the Session. Second, be sure not to create unneeded session variables. Finally, make sure that you have set a reasonable value for the Timeout property.

    If you want to maintain state for a period longer than the user's visit to your site, you will need to use cookies. Some Web surfers, unfortunately, will have their browsers set up not to receive cookies. However, these people are in the minority. If you need to ensure that every user can have state maintained, whether or not they accept cookies, you will need to use the querystring method discussed in the section "Passing Information Through the Querystring," or you will have to use Cookie Munger to simulate cookie usage.


Thank you for reading the sample chapter from Sams Teach Yourself Active Server Pages 3.0 in 21 Days!
I hoped you enjoyed reading this chapter! Hopefully you found the chapter interesting and the writing style informative and easy to follow. Before you go, be sure to check out these helpful links!


ASP.NET [1.x] [2.0] | ASPMessageboard.com | ASPFAQs.com | Advertise | Feedback | Author an Article