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, many applications must 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 the client state by seamlessly tracking variables associated with a browser as the user moves from page to page within the application. You can use these variables in place of other methods for tracking client state, such as URL parameters, hidden form fields, and HTTP cookies.
About client and session variables
ColdFusion provides two tools for managing the client state: client variables and session variables. Both types of variables are associated with a specific client, but you manage and use them differently, as described in the following table:
|
Variable type |
Description |
|---|---|
|
Client |
Data is saved as cookies, database entries, or Registry entries. Data is saved between server restarts, but is initially accessed and saved more slowly than data stored in memory. Each type of data storage has its own time-out period. You can specify the database and Registry data time-outs in the ColdFusion Administrator. ColdFusion sets Cookie client variables to expire after approximately 10 years. Data is stored on a per-user and 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 simple variables, such as numbers, dates, or strings. They cannot be arrays, structures, query objects, or other objects. Client variable names can include periods. For example, My.ClientVar is a valid name for a simple client variable. Avoid such names, however, to ensure code clarity. You do not have to prefix client variables with the scope name when you reference them, However, if you do not use the Client prefix, you might unintentionally refer to a variable with the same name in another scope. Using the prefix also optimizes performance and increases program clarity. You do not lock code that uses client variables. You can use client variables that are stored in cookies or a common database in clustered systems. |
|
Session |
Data is stored in memory so it is accessed quickly. Data is lost when the client browser is inactive for a time-out period. You specify the time-out in the ColdFusion Administrator, the Application.cfc initialization code, or Application.cfm. As with client variables, data is available to a single client and application only. Variables can store any ColdFusion data type. You must prefix all variable names with the Session scope name. Lock code that uses session variables to prevent race conditions. You can use session variables in clustered systems only if the systems support "sticky" sessions, where a session is limited to a single server. |
Session variables are normally better than client variables for values that need to exist for only a single browser session. You should reserve client variables for client-specific data, such as client preferences that you want available for multiple browser sessions.
Maintaining client identity
Because the web is a stateless system, client management requires some method for maintaining knowledge of the client between requests. Normally you do this using cookies, but you can also do it by passing information between application pages. The following sections describe how ColdFusion maintains client identity in a variety of configurations and environments, and discuss issues that can arise with client state management.