You may remember that Session variables are stored in memory, whereas Client variables are stored in a disk structure. The internal structure of the Session variables in memory is unimportant, but the options for storing Client variables deserve some discussion. By default, ColdFusion stores Client variables in the Windows Registry. As you can see, all the Client variables assigned to a given session are stored under a key that takes its name from the CFID and CFTOKEN of a given session. The problem is that the Windows Registry was never intended as a high-speed data-storage and -retrieval system, and large numbers of consecutive accesses can affect a server’s performance. A better option is to store Client variables on a database server. This is slightly more involved than storing data in the Registry. You must first set up the database as one that ColdFusion can use for Client-variable storage. To do so, follow these steps:

1. In ColdFusion Administrator, set up a ColdFusion datasource in which to store client variables. (It should be an actual database server, such as Microsoft SQL Server or Oracle and not a file-based product such as Microsoft Access.)

2. Go to Client Variables of ColdFusion Administrator, choose the datasource that you just created, and click Add.

3. Give the datasource a meaningful description, leave all the check boxes in their default positions, and click Submit. Modify the check-box settings only if you’re absolutely sure that you need to. After following those steps, your database now contains two new articles: CDATA and CGLOBAL. CDATA contains the client variable data, and CGLOBAL contains global information for each session, such as the hit count and time of last visit. To start using the Client variables database, you can do one of the following two things:

Set the datasource as the default Client-variable storage option in ColdFusion Administrator. This is a good idea because none of your code must change to support it. This is not a good idea, however, if you run multiple Web sites with multiple Clientvariable databases, because you may inadvertently store variables in the wrong place.

Use the CFAPPLICATION tag as follows:

<cfapplication
   ... clientstorage=”MyDataSourceName”>

This is a better option in general, as it gives you more granular control over where your client variables are stored.

Notice that enabling J2EE Session Management now splits the state-management mechanism for Session and Client. Session variables now use JSESSIONID to identify the user’s session, but Client variables still use CFID and CFTOKEN, because Client variables are not interoperable with JSP, as Session variables are. With J2EE session management enabled, CFML can share its Request, Session, and Application scopes with JSP and J2EE Servlet applications. You can’t share Client variables with these non-ColdFusion applications, however, because J2EE doesn’t use them. To enable J2EE session management, log in to ColdFusion Administrator and go into the Memory Variables part. Select the Use J2EE Session Variables checkbox and click Submit. Restart both ColdFusion server and your Web server after enabling this option. We mention URLSessionFormat(), which automatically appends the CFID and CFTOKEN to a page’s URL only if needed. You can also use URLSessionFormat() to add JSESSIONID to the URL if necessary. You do face a problem, however, in using URLSessionFormat() while J2EE sessions are enabled. If J2EE sessions are enabled, however, URLSessionFormat() instead creates a URL. Notice that, instead of a question mark as in the first example, a semicolon introduces JSES SIONID. The semicolon is part of the J2EE Servlet standard, but Microsoft’s Internet Information Server and Apache Web Server may not recognize the semicolon as valid. As such, attempting to use the URL from URLSessionFormat() if J2EE sessions are enabled may lead to a 404 File Not Found error if running against these incompatible Web servers. Adding Client variables to the mix complicates the problem even more. Notice that the semicolon is still there before JSESSIONID but that the normal question mark that introduces the query string is appended after the JSESSIONID. Notice, too, that JSESSIONID is included twice, but the second version is lowercase, in violation of the J2EE standard. (However, because JSESSIONID appears in uppercase, ColdFusion knows what to do; it’s just confusing to see.) The best solution is to use URLSessionFormat() if your Web server supports a semicolon as the character that delimits the URL from its parameters; if not, append Session.URLToken to the page URL, as follows:

<a href=”page.cfm?#UCase(Session.URLToken)#”>...</a>

Why do we use UCase()? Unfortunately, the JSESSIONID parameter that’s part of Session.URLToken is included as a lowercase parameter; J2EE, however, requires that JSESSIONID be included as uppercase. If you don’t include the call to UCase(), state is not maintained between requests. One important detail of ColdFusion development that is often sadly overlooked is the application framework, which boils down to two parts: effective use of Application.cfm, OnRequestEnd.cfm, and the CFAPPLICATION tag. One file that will exist in almost every ColdFusion application is Application.cfm. ColdFusion executes this file before every page request, making Application.cfm an excellent place to set variables that every page request can use, such as the name of your datasource, the database username and password, and other global constants. In addition, ColdFusion will also execute a template named OnRequestEnd.cfm after every page request, making OnRequestEnd.cfm an ideal place to put footer code for your site. When you request a ColdFusion template, the first thing ColdFusion does is look for Application.cfm in the directory that contains the template you requested. If ColdFusion finds Application.cfm, the search stops and ColdFusion executes Application.cfm. If there is not an Application.cfm in the current directory, ColdFusion searches each directory in the requested template’s path until ColdFusion finds a file named Application.cfm. For example, if you requested c:\inetpub\wwwroot\mydirectory\mytemplate.cfm, ColdFusion would search for Application.cfm in the following directories in this order:

c:\inetpub\wwwroot\mydirectory\
   c:\inetpub\wwwroot\
   c:\inetpub\
   c:\

If ColdFusion doesn’t find an Application.cfm anywhere in the requested template’s directory hierarchy, ColdFusion simply executes the requested template. When the requested template finishes, ColdFusion looks in the same directory where it found Application.cfm for a file named OnRequestEnd.cfm. If ColdFusion doesn’t find OnRequestEnd.cfm in the same place as Application.cfm, ColdFusion simply ends the request. OnRequestEnd.cfm doesn’t follow the same directory traversal process that Application.cfm does. The problem is knowing where to put Application.cfm and OnRequestEnd.cfm. Some applications put an Application.cfm in every single directory in the application, whereas others don’t include Application.cfm at all. The best practice lies somewhere in between these two extremes; I usually have only one Application.cfm at the root of the directory structure for my entire application. I will, however, add an Application.cfm anywhere that it’s absolutely necessary, but I’m very careful to add an Application.cfm only where I have a compelling reason to do so. CFAPPLICATION is the cornerstone of ColdFusion’s application framework. Without CFAPPLICATION, you wouldn’t be able to set Client, Session, or Application variables, and you wouldn’t be able to maintain state because CFAPPLICATION is ColdFusion’s mechanism for handling CFID and CFTOKEN. The state management aspects of CFAPPLICATION were mentioned earlier, but one attribute of CFAPPLICATION that is unfortunately often overlooked is the name attribute:

<cfapplication
   name=”MyApp”>

The name attribute of CFAPPLICATION partitions Application, Session, and Client variables into separate application spaces. If you call CFAPPLICATION with a name of MyApp in one request and a name of YourApp in another request, neither request will share the other’s Application, Session, or Client variables because the two requests are in different application spaces. The point is that all the CFAPPLICATION tags in your entire application should always reference the same application name. Some developers try to split the application into different parts, but don’t do this. Splitting a single application into multiple application spaces backfires every time because the developer will invariably forget that templates in one application space use different Session variables than templates in another application space. Keep it simple and use only one application name for every request in your application.