ASP Tips: Tip 2: Cache Frequently-Used Data in the Application or Session Objects

The ASP Application and Session objects provide convenient containers for caching data in memory. You can assign data to both Application and Session objects, and this data will remain in memory between HTTP calls. Session data is stored per user, while Application data is shared between all users.

At what point do you load data into the Application or Session? Often, the data is loaded when an Application or Session starts. To load data during Application or Session startup, add appropriate code to Application_OnStart() or Session_OnStart(), respectively. These functions should be located in Global.asa; if they are not, you can add these functions. You can also load the data when it's first needed. To do this, add some code (or write a reusable script function) to your ASP page that checks for the existence of the data and loads the data if it's not there. This is an example of the classic performance technique known as lazy evaluation-don't calculate something until you know you need it. An example:

<%
Function GetEmploymentStatusList
 Dim d
 d = Application("EmploymentStatusList")
 If d = "" Then
    ' FetchEmploymentStatusList function (not shown)
    ' fetches data from DB, returns an Array
    d = FetchEmploymentStatusList()
    Application("EmploymentStatusList") = d
 End If
 GetEmploymentStatusList = d
End Function
%>

Similar functions could be written for each chunk of data needed.

In what format should the data be stored? Any variant type can be stored, since all script variables are variants. For instance, you can store strings, integers, or arrays. Often, you'll be storing the contents of an ADO recordset in one of these variable types. To get data out of an ADO recordset, you can manually copy the data into VBScript variables, one field at a time. It's faster and easier to use one of the ADO recordset persistence functions GetRows(), GetString() or Save() (ADO 2.5). Full details are beyond the scope of this article, but here's a function that demonstrates using GetRows() to
return an array of recordset data:

' Get Recordset, return as an Array

Function FetchEmploymentStatusList
 Dim rs
 Set rs = CreateObject("ADODB.Recordset")
 rs.Open "select StatusName, StatusID from EmployeeStatus", _
         "dsn=employees;uid=sa;pwd=;"
 FetchEmploymentStatusList = rs.GetRows() " Return data as an Array
 rs.Close
 Set rs = Nothing
End Function

A further refinement of the above might be to cache the HTML for the list, rather than the array. Here's a simple sample:

' Get Recordset, return as HTML Option list
Function FetchEmploymentStatusList
 Dim rs, fldName, s
 Set rs = CreateObject("ADODB.Recordset")
 rs.Open "select StatusName, StatusID from EmployeeStatus", _
         "dsn=employees;uid=sa;pwd=;"
 s = "<select name=""EmploymentStatus">" & vbCrLf
 Set fldName = rs.Fields("StatusName") ' ADO Field Binding
 Do Until rs.EOF
   ' Next line violates Don't Do String Concats,
   ' but it's OK because we are building a cache
   s = s & " <option>" & fldName & "</option>" & vbCrLf
   rs.MoveNext
 Loop
 s = s & "</select>" & vbCrLf
 rs.Close
 Set rs = Nothing ' See Release Early
 FetchEmploymentStatusList = s ' Return data as a String
End Function

Under the right conditions, you can cache ADO recordsets themselves in Application or Session scope. There are two caveats:

• ADO must be marked Free-threaded
  
• You need to use a disconnected recordset.

If you cannot guarantee that these two requirements will be met, do not cache ADO recordsets. In the
Non-Agile Components and Don't Cache Connections tips below, we discuss the dangers of storing COM objects in Application or Session scope.

When you store data in Application or Session scope, the data will remain there until you programmatically change it, the Session expires, or the Web application is restarted. What if the data needs to be updated? To manually force an update of Application data, you can call into an administrator-access-only ASP page that updates the data. Alternatively, you can automatically refresh your data periodically through a function. The following example stores a time stamp with the cached data and refreshes the data after a certain time interval.

<%
' error handing not shown...
Const UPDATE_INTERVAL = 300 ' Refresh interval, in seconds
' Function to return the employment status list
Function GetEmploymentStatusList
 UpdateEmploymentStatus
 GetEmploymentStatusList = Application("EmploymentStatusList")
End Function

' Periodically update the cached data
Sub UpdateEmploymentStatusList
 Dim d, strLastUpdate
 strLastUpdate = Application("LastUpdate")
 If (strLastUpdate = "") Or _
       (UPDATE_INTERVAL < DateDiff("s", strLastUpdate, Now)) Then

    ' Note: two or more calls might get in here. This is okay and will simply
    ' result in a few unnecessary fetches (there is a workaround for this)

    ' FetchEmploymentStatusList function (not shown)
    ' fetches data from DB, returns an Array
    d = FetchEmploymentStatusList()

    ' Update the Application object. Use Application.Lock()
    ' to ensure consistent data
    Application.Lock
    Application("EmploymentStatusList") = d
    Application("LastUpdate") = CStr(Now)
    Application.Unlock
 End If
End Sub

For another example, see World's Fastest ListBox with Application Data.

Be aware that caching large arrays in Session or Application objects is not a good idea. Before you can access any element of the array, the semantics of the scripting languages require that a temporary copy of the entire array be made. For example, if you cache a 100,000-element array of strings that
maps U.S. zip codes to local weather stations in the Application object, ASP must first copy all 100,000 weather stations into a temporary array before it can extract just one string. In this case, it would be much better to build a custom component with a custom method to store the weather stations—or to use one of the dictionary components.

One more comment in the spirit of not throwing out the baby with the bath water: Arrays provide fast lookup and storage of key-data pairs that are contiguous in memory. Indexing a dictionary is slower than indexing an array. You should choose the data structure that offers the best performance for your situation.