Managing the Client State

Because the Web is a stateless system, each connection that a browser makes to a Web server is unique to the Web server. However, within an application it is important to be able to keep track of users as they move through the pages within the application. This is the definition of client state management.

ColdFusion provides tools to maintain client state by seamlessly tracking variables for a browser as the user moves from page to page within the application. These variables can be used in place of other methods for tracking client state, such as using URL parameters, hidden form fields, and HTTP cookies.

About Client and Session variables

ColdFusion provides you with two tools for managing the client state: Client variables and Session variables. Both types of variables are tied to a specific client, but they have significant differences in how they are managed and when they should be used:

Variable Type

Description

Client
Data saved as cookies, database entries, or Registry entries, but is accessed more slowly than data stored in memory.
Each type of data storage has its own timeout period. You can specify the database and Registry data timeouts in ColdFusion Administrator. Cookie life depends on the user's system.
Data is stored on a per-application basis. For example, if you store Client variables as cookies, the user has a separate cookie for each ColdFusion application provided by a server.
Client variables must be strings (or represented as strings). They cannot be arrays or structures.
You do not need to lock code that uses Client variables.

Session
Data is stored in memory so it is accessed quickly.
Data is lost when the client browser is inactive for a timeout period. You specify the timeout in the ColdFusion Administrator and Application.cfm.
Data is available to a single application only.
Session variables can be any ColdFusion Data type.
You can access the Session scope as a ColdFusion structure.
You must lock Session code that uses variables to prevent simultaneous access, for example from different frames.

Variable Type	Description
Client	Data saved as cookies, database entries, or Registry entries, but is accessed more slowly than data stored in memory. Each type of data storage has its own timeout period. You can specify the database and Registry data timeouts in ColdFusion Administrator. Cookie life depends on the user's system. Data is stored on a per-application basis. For example, if you store Client variables as cookies, the user has a separate cookie for each ColdFusion application provided by a server. Client variables must be strings (or represented as strings). They cannot be arrays or structures. You do not need to lock code that uses Client variables.
Session	Data is stored in memory so it is accessed quickly. Data is lost when the client browser is inactive for a timeout period. You specify the timeout in the ColdFusion Administrator and Application.cfm. Data is available to a single application only. Session variables can be any ColdFusion Data type. You can access the Session scope as a ColdFusion structure. You must lock Session code that uses variables to prevent simultaneous access, for example from different frames.

As a general rule, it is best to use Session variables for any values that need to exist for only a single browser session. You should reserve Client variables for client-specific data that you want available for multiple browser sessions, such as client preferences.

About client cookies

Both types of variables normally require ColdFusion to store two client identification variables as cookies on the client's system:

CFID, a sequential client ID
CFToken, a random-number client security token

These cookies uniquely identify the client to the ColdFusion Server, which also maintains copies of the variables. You can configure your application so that it does not use client cookies at all, but you must then pass these variables to all pages your application calls.

Managing client state in a clustered environment

To maintain your application's client state in a clustered server environment, you can store the server-side client identification variables in a common, back-end repository that all Web servers in a multiserver clustered environment can access. You enable use of a common repository by specifying the cfapplication setdomaincookies attribute in your Application.cfm page.

This attribute specifies that the server-side copies of the CFID and CFToken variables used to identify the client to ColdFusion are stored at the domain level (for example, .macromedia.com). If CFID and CFToken combinations already exist on each host in the cluster, ColdFusion migrates the host-level variables on each cluster member to the single, common domain-level variable. Following the setting or migration of host-level cookie variables to domain-level variables, ColdFusion creates a new cookie variable (CFMagic) that tells ColdFusion that domain-level cookies have been set.

Managing client state without cookies

You can use ColdFusion's client state management without cookies, however, this is not recommended. If you choose to maintain client state without cookies, you must ensure that every request carries the CFID and CFToken variables.

To maintain client state without cookies, set the setClientCookies attribute of the cfapplication tag to No. Then, you must maintain client state by passing CFID and CFToken between pages, either in hidden form fields or appended to URLs. You accomplish this using the variable Client.URLToken or Session.URLToken. (The values of these two variables are the same.)

Developing ColdFusion Applications
Using the Application Framework