| Downloads |
|---|
| 7637.zip |
Active Server Pages (ASP) Session and Application variables make it easy for you to store and maintain session information (temporary data that an application stores between a user's visits to the Web application). ASP applications use a global.asa file to store information for use globally in an application. For example, you might create a Session variable such as this one in a global.asa file.
Session("UserName") = " "
Later, you can set the variable:
Session("UserName") = "John Doe"
These Session statements make the username available to use in the ASP pages that the current user visits within the application's scope. The UserName variable isn't available to other users of the same application; it's a private variable for only the UserName variable user's data. Session variables are useful for storing information, such as login names or other user data, but using a Session variable costs memory overhead. Session variables make it easy for you to store and manipulate data.
Application variables provide another way to store information in your application, and they're available to all the application's users. For example, you can use Application variables in Visual InterDev to store information about data connections, as Callout A in Listing 1, page 56, shows. When you add a new data source to the Web project, Visual InterDev adds the data source definition to your global.asa file.
Session variables and Application variables have different functions. When you create an Application variable, that variable's data exists only once for that application on the Web server. The script requires only a small amount of server memory to hold the definition for the data source. In contrast, you can create a Session variable for each user of an application. You can also create the database connection information and store it in Session variables to give you a copy for the application's users. But if 1000 users connect at the same time, 1000 copies of that information will consume memory on the Web server and bog it down.
Because Session variables consume memory resources, they can force a Web server to run out of memory, depending on what's stored in the variables and how many users visit the application at approximately the same time. When a Web server is low on memory, paging starts and performance diminishes.
Application variables are fine for some static information, but be careful when you use Session variables. They can drag down your performance.
Scalability
Windows Load Balancing Service and DNS routers let you scale Web applications to accommodate many users. You can group several servers together and route users to different servers to distribute the load. Servers, such as some DNS routers, don't consider Session and Application variables. These servers simply route users to another server without regard for the server they last visited. Because Session and Application variables are part of an Internet Information Server (IIS) application, they don't span servers. To use the variables, a user must return to the same server while using that server's application. Windows Load Balancing Service has an Affinity setting that causes the server to route users to the same server repeatedly during their use of an application, which results in the ability to use Session and Application variables. However, performance might suffer. The Affinity setting works with Session and Application variables and reroutes users to the same server, letting you use both Session and Application variables in your application.
Although you can use the Affinity setting with Application and Session variables, doing so doesn't reduce the problem of loading when too many users access the server.
Another solution for storing session (user) data is to use a high-performance database to store the session data such as SQL Server. Then you can pass the session record's key to the session record for each page. The key you pass to each page then becomes the key to the session record in the database.
Session IDs
When using a database to uniquely identify the session ID for a user, you don't use the ASP-provided SessionID as the session key. ASP doesn't guarantee that the SessionID is unique across restarts of IIS or across servers. You can create your own session ID by combining the server name, date, time, etc., in a short ASP script, which creates a unique session ID for the user, as Listing 2 shows.
The script creates a new variable, MySessionID, to store the new session ID and a variable to hold the application name. The code uses the SCRIPT_NAME variable to grab the script name from the ServerVariables collection. Then the code uses the Instr function to search for the second forward slash in the script name after the name of the Web applications folder and before the script filename. Then the Mid function extracts the Web application's folder name from the string. This folder name is the same as the application name and is now stored in the AppName variable. I designed this script to run in a virtual directory. After you place the script in a Web's root, you need to change the code to work without the reference to the directory.
Next, the code uses the Request object's ServerVariables method to grab the server name and place the server name in the MySessionID variable. The SERVER_NAME variable extracts the server name from the ServerVariables collection. The next part of this assignment statement appends the AppName variable's contents to the string. The code then appends the current date and time and uses the Replace function to remove all spaces from the date/time string. Finally, the last part of the statement appends the SessionID to the string from the Session object. The result is a unique session ID that resembles
SQLMagWebDev10/13/994:41:03PM1004361785
This technique makes the session ID unique for the server by combining the server name, application name, and date and time. The session ID makes this string unique for this particular session on the server.
Session variables are useful for many Web applications because they make it easy to program session support into the application, and not all applications need to support thousands of users. Application variables don't require the same amount of overhead that session variables do, and as a result, they're less susceptible to scaling issues. You need to decide when and whether to use these techniques and how well your application needs to scale to use these variables.