Variables in CFML; Server and Application Scopes

Data stored in Server and Application scopes are persistent and can exist across multiple requests. They are not tied to a specific end user or client machine. Data stored in these scopes is maintained in the server's system RAM and along with the Session scope (described later) are called "Shared Variable Scopes" due to the fact that acess to these scopes is shared among all active requests. An understanding of locking in CFML is required to use them properly. Locking is covered in detail in our Guide to Locking.

Because information is stored in system RAM considerations should be made to size your application's use of these scopes to the hardware on which it will run. This also means that data in these scopes are not available across machines in a ColdFusion cluster. Data in these scopes will not persist beyond a server reboot or CF service restart so the application should be designed to test and properly react to restarts.

Server Scope

Data stored in the server scope is available to any CF template running on the same server instance. This means that any template running on the server can view and manipulate these variables.

Several Server scoped variables are created automatically by ColdFusion. These are:

Server.ColdFusion.ProductName
Server.ColdFusion.ProductVersion
Server.ColdFusion.ProductLevel
Server.ColdFusion.SerialNumber
Server.ColdFusion.SupportedLocales
Server.ColdFusion.RootDir (Only in CFMX)
Server.OS.Name
Server.OS.AdditionalInformation
Server.OS.Version
Server.OS.BuildNumber
Server.OS.Arch (Only in CFMX)

The Server scope is accessible as a structure in CFMX but not in previous versions.

Recommendations

As noted the Server scope is shared across the entire server. Unless your server is dedicated and under centralized control it's generally not a good idea to make use of the Server scope. Remember that in CFMX anybody with access to the server can discover, access and change all Server scoped variables.

Application Scope

The scope is accessible only by requests that use the <CFAPPLICATION> tag. Each named application (using the NAME attribute of the <CFAPPLICATION> tag) maintains a separate application scope. This can be illustrated with the following templates:

Request One	Request Two
<cfapplication name="AppOne"> <cfset application.myVar = 5> <cfoutput> #application.myVar# </cfoutput>	<cfapplication name="AppTwo"> <cfset application.myVar = 10> <cfoutput> #application.myVar# </cfoutput>

These two templates create two separate application scopes: the "AppOne" application scope and the "AppTwo" application scope. Because of this the myVar variable of each template is completely independent of the other. ColdFusion automatically generates the variable Application.ApplicationName which contains the value of the NAME attribute.

The Application scope will time out (be automatically emptied) after a set period of inactivity. Default and maximum timeout values may be set in the ColdFusion administrator; the default is two days (48 hours). Additionally the timeout may be set programmatically (but not higher than the defined maximum) using the APPLICATIONTIMEOUT attribute of the <CFAPPLICATION> tag. The ColdFusion CreateTimeSpan() function is used to set the timeout.

The <CFAPPLICATION> tag may be run in any template that makes up a request, however the Application scope is not available until the tag is run. At that point the request can be considered a member of the application. Although not recommended the <CFAPPLICATION> tag can be run multiple times in the same template. For example if the above two templates have been run already the following template is perfectly legal:

Request Three
<cfapplication name="AppOne"> <cfoutput> #application.myVar# </cfoutput> <cfapplication name="AppTwo"> <cfoutput> #application.myVar# </cfoutput>

The above template would output "5 10". Although CFML allows you to change the application membership of a request on the fly like this there's rarely any legitimate reason to.

The application scope is accessible as a structure in CF 4.5 and above.

Recommendations

The application scope is designed to store information global to an application. For example you may decide to store application configuration settings or contact data in the application scope. Note that the Application scope must still be locked properly however so in many cases the Request scope may be a better choice. This is especially true for simple, static information like datasource names and such.

Information that is used often but takes some time to gather or manipulate is a perfect candidate for the Application Scope. For example your company may have a list of district offices that rarely changes but is presented on every page as a "quick jump" select box. You might consider placing that list in the Application scope. In some cases however it may be easier to use ColdFusion's built in query caching for such a purpose when the information comes from a database.

The Application scope may also be used to store application-level diagnostic information such as access or pages counts (but remember that any information in the scope will be erased during a server reboot and may timeout).