|
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:
<!--#include virtual="/lib_connection.asp"-->
... 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.
|