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:

<%
  Dim db
  Set db = Server.CreateObject("ADODB.Connection")
  db.Open("DBALIAS")
  Application("MYDB") = db
%>
... Do something with the DB ...

Fragment from page 2:

<%
  Dim db
  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
End If
' 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.Lock
Application("AppPageCountVBScript") = Application("AppPageCountVBScript") + 1
Application.UnLock
%>
<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 better a 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.

Further 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 efforts. 

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 file.