|One of the most difficult
problems in the WEB based programming is the stateless nature of the
request-response techniques. This means that each page is executed for
itself and there is no general state information kept between the
requests. Most WEB environments offer some solutions and ASP is one of
them. In ASP we have two objects available to all the pages in certain
scope where the pages can save and retrieve data which is preserved
across the requests.
The Application object is
available to the entire application and lives from the application
start to the moment when the application is unloaded. It is used to
hold non-user specific information and objects needed by the entire
application. For example some enumerations can be cached (items used
to fill frequently used list boxes) or a data base connection can be
made once and kept there or an object that manages certain file (for
example log file, configuration file or something else) and so on.
Advanced usage of the Application object allows the application
synchronize access to shared resources and/or provide some common
functionality through a COM object used in many pages.
The Session object is
available for an user session. The user session in ALP is almost
equivalent to the application because of the single-user nature of the
client environment, but still it reflects the
interaction of a particular user with the application and should be
used accordingly. The ASP session is created when the user first sends
a request to the application and is destroyed if the user stops using
the application for some configurable time or explicitly. During the
Session's life time it is accessible to all the pages in the
application and they are able to keep there data and objects as like
in the Application object.
So, the values kept in these objects are kept after a particular
page execution finishes and are available further during the next
requests. Before discussing the details about how an ASP application
is defined/configured and initialized let us take an expample:
Suppose we have two pages in one application:
Fragment of page 1:
Set db = Server.CreateObject("ADODB.Connection")
Application("MYDB") = db
... Do something with the DB ...
Fragment from page 2:
Set db = Application("MYDB")
... Do something with the DB ...
Or another simple example counting the visits to the page:
' If this is the first time any user has visited
' the page, initialize Application Value
if IsEmpty(Application("AppPageCountVBScript")) Then
Application("AppPageCountVBScript") = 0
' Increment the Application AppPageCount by one.
' Note that locking the application is used.
' Altough that ALP works on the desktop browser different windows
' may want to change the variable.
' Of course this can be nearly impossible situation on the desktop
' and can be omitted but if the script is to be placed on a WEB server
' absence of locking will cause it to operate incorrectly.
Application("AppPageCountVBScript") = Application("AppPageCountVBScript") + 1
<p>Visists to this page:<%= Application("AppPageCountVBScript") %></p>
It is important to know that not every object can be stored to the Application and
Session collections. Internal scripting language objects can not be stored there if
created in the page because they will become unavailable after finishing the page!
This includes the JScript objects and the VBScript objects defined
with the Class keyword. This
note is very important for the JScript programmers because JScript arrays are objects
implemented by the JScript engine and not independent OS supported
structures like in VBScript - in that case you will need to create a VBArray or
collection from the ALP run-time
library (see VarDictionary or UtilStringList or ConfigFile objects
for different ways to keep structured application data) in order to save
array values in that object and then store it into the Application or Session collections.
if you still want to put in the Application or Session some objects,
libraries written in a scripting language (VBScript, JScript etc.) and
make them available to all the regular pages in the application you
can do so by using the ALP run-time library. See the composite
objects section, the COMScriptThread
object and the COMThread and the other advanced COM classes. The
ALP run-time library allows several different ways to use common code
without the need to include it in each page. Also it allows you to run
script code in separate threads and thus perform slow operations in
the background (typical for the desktop applications but quite unusual
in ASP). You will notice that most of the techniques enabled by the
mentioned ALP run-time library objects can be used on a WEB server as
well. You just need to install the ActiveX
Pack1 DLL there and the objects from the ALP run-time library will
be available for the WEB application. There is only general
consideration is the multi-client nature of the classic ASP and the
single-user nature of ALP. Thread usage should be designed to meet the
performance requirements of the scenario. For example in classic ASP
you should limit the number of threads even if the application uses
only one per user while in ALP you can just forget about that. In most
cases common solution can be developed without additional
Another consideration is the classic ASP
compatibility. ALP is more tolerant to the objects stored in the
Application and Session collections and the the way they are stored
there. This especially concerns the Application and the non-free
threaded COM objects. Therefore if you require compatibility with the
classic ASP you should carefully check the classic ASP requirements
and the objects you are going to use, because in most cases ALP will
accept any object you want to hold in the Application but this will
not be so in the classic ASP. One general advise is creating and
initializing such objects in the global.asa where the ALP and classic
ASP behavior match completely.
See the next chapter - Application
boundaries and the Global.asa