Datacheck Solutions :: ASP

Tutorials
Back

Global.asa Overkill

by Charles Carroll

A global.asa file is a used extraneously and quite wastefully, but can be a very useful tool. First let us bring out what is good and bad about it.

Application variables are good. Since there is only one application variable in memory, no matter how many users are on your site, they can be a convenient place to store central information and retrieve it fast. Since there is only one application variable in memory regardless of the number of users at your site, remember the following characteristics:

Of course Application variables have no dependence on cookies. They are not required at all. 
If a object or variable is accessed concurrently for anything other than reading it's value, this is a potential concurrency issue that needs to be carefully coded so that no problems arise, i.e.
<%
application.lock
   ... modify app object ...
application.unlock
%> 
Session variables (particularly COM objects put in a session variable) can:

waste memory because they live for ___ minutes past their last use. ___ depends on your session. timeout, the default is 20 minutes. See /freebook/asp/nosessionobjects.aspx for more details. 
waste threads if you put any objects (made with server.createobject) in a session variable. See /freebook/asp/buildvbthreads.aspx for more details. 
limit the code to users accepting cookies which may mean someone who disables cookies may not use that script at all. 
Session Variable Constraints

Session variables containing simple variables (texts, numbers, dates, NOT COM objects) are not so wasteful as to be prohibitive. BUT remember, if you write any script that depends on session variables you are working under the following assumptions (and if these restrictions are fine, then use sessions as much as you need to):

the person browsing your site MUST enable cookies for your script to function. 
If your site is one giant application (i.e. the root folder is marked as an application) the person browsing the site will have access to their session variables in every script BUT if individual folders are marked as applications, all scripts within that directory set session variables that cannot be read from scripts in other folders marked as applications.
In other words three folders: \A, \B and \C can set session variables but cannot see each others. If your goal with a session is to attach people to data and use it in many scripts this visibility can be an issue. 
the person using the scripts will never gets "switched" to another server in a web farm situation. 
If the task could be accomplished with hidden fields instead of session variables, then those limitations are not in effect -- and most tasks can.

Good uses of global.asa and session data include:

if you place any value in an Application_OnStart event that sets application variables, this is not wasteful and can be quite useful. 
If you place any non-object data in session variables the waste is not excessive. 
Examples of Wasteful Code and Alternatives...

Code that is particularly wasteful is code that places database connection info in the global.asa, i.e.

session_onstart
   session("dbname")="DSN=employees;"
   session("dbuser")="whoever"
   session("dbpass")="majic"
end sub

and the script that goes with it looks like this:

... code ....
set conntemp=server.createobject("adodb.connection")
conntemp.open session("dbname") & "uid=" & session("dbuser") & ";pwd=" & session("dbpass")
... code ....

Why? Do 700 users hitting that site hit 700 different databases with 700 different userids and passwords at the database level. Just 700 wasted session variables...Session variables are the worst way to keep such data; application variables the best or other mechanisms. Unfortunately Visual Interdev grossly misuses sessions and creates this bizzare concept in people's brains.

If for example, 700 users connect to a page using session variables to store DSN info, etc. You have 700 DSN variables in memory all with the same value. The purpose of sessions is to have separate data for users not the same data replicated for every session. Plus it means the site is unusable to a user not accepting cookies unnecessarily. It is really necessary to require cookies to display a database page where the DSN to the database does NOT change over a multi-month/year period?

The better alternatives would be:

Include Files (cheap and easy)

lib_connection.asp

<%
dbname="DSN=employees;"
dbuser="whoever"
dbpass="majic"
%>

and the script that goes with it looks like this:

... code ....
set conntemp=server.createobject("adodb.connection")
conntemp.open dbname & "uid=" & dbuser & ";pwd=" & dbpass
... code ....

Application Data (involves a COM object, but is memory cheap)

application_onstart
   application("dbname")="DSN=employees;"
   application("dbuser")="whoever"
   application("dbpass")="majic"
end sub

and the script that goes with it looks like this:

... code ....
set conntemp=server.createobject("adodb.connection")
conntemp.open application("dbname") & "uid=" & application("dbuser") & ";pwd=" & application("dbpass")
... code ....

In both approaches, if 700 users hit the site, no user specific variables are created. The same three variables are available to all users with no wasted memory.