Application variables are available to all pages within an application, that is, pages that have the same application name. Because application variables are persistent, you easily can pass values between pages. You can use application variables for information including the application name, background color, data source names, or contact information.
You set the application name in the cfapplication
tag, normally on your application's Application.cfm page. The application name is stored in the Application.applicationName
variable.
Unlike client and session variables, application variables do not require that a client name (client ID) be associated with them. They are available to any clients that use pages in the application.
Caution: To preserve data integrity, put code that uses application variables inside cflock
tags. For information on using cflock
tags see "Locking code with cflock".
The following sections describe how to configure and use application variables.
To use application variables, do the following:
cfapplication
tag for the current page. Note: ColdFusion supports unnamed applications for compatibility with J2EE applications. For more information see "Unnamed ColdFusion Application and Session scopes," in Chapter 32.
The ColdFusion MX Administrator also lets you specify the following information:
cfapplication
tag can override this value for a specific application. The default value for this time-out is two days.
cfapplication
tag cannot set a time-out greater than this value. The default value for this time-out is two days.
You can set the time-out period for application variables within a specific application by using the applicationTimeout
attribute of the cfapplication
tag.
Application variables are a convenient place to store information that all pages of your application might need, no matter which client is running that application. Using application variables, an application could, for example, initialize itself when the first user accesses any page of that application. This information can then remain available indefinitely, thereby avoiding the overhead of repeated initialization.
Because the data stored in application variables is available to all pages of an application, and remains available until a specific period of inactivity passes or the ColdFusion Server shuts down, application variables are convenient for application-global, persistent data.
However, because all clients running an application see the same set of application variables, these variables are not appropriate for client-specific or session-specific information. To target variables for specific clients, use client or session variables.
Generally, application variables should hold information that you write infrequently. In most cases, the values of these variables are set once, most often when an application first starts. Then the values of these variables are referenced many times throughout the life of the application or the course of a session.
To preserve data integrity, you must put all code that writes to Application scope variables or reads Application scope variables with data that can change inside cflock
tags.
Because each Application scope variable is shared in memory by all requests in the application, these variables can become bottlenecks if used inappropriately. Whenever a request is reading or writing an Application scope variable, any other requests that use the variable must wait until the code accessing the variable completes. This problem is increased by the processing time required for locking. If many users access the application simultaneously and you use Application scope variables extensively, your application performance might degrade. If your application uses many application variables, consider whether the variables must be in the Application scope or whether they can be Session or Request scope variables.
The application scope has one built-in variable, Application.applicationName
, which contains the application name you specify in the cfapplication
tag.
You access and manipulate application variables the same way you use session variables, except that you use the variable prefix Application, not Session, and specify Session as the lock scope. For examples of using session variables see "Creating and deleting session variables" and "Accessing and changing session variables".
For information on locking write-once read-many application variables efficiently, see "Locking application variables efficiently"