|By Charlie Arehart||
|July 11, 2001 12:00 AM EDT||
You've probably seen the use of a variable called "application.dsn" (or "application.datasource") in code. Perhaps you've even been taught to use the method in a class.
Maybe you've even been doing it in your own code. I'm talking about setting this variable in the application.cfm file to hold the name of your data source for a given application.
It seems so innocuous, and it seems to provide ways to make your code easier to maintain (change the dsn variable once in the application.cfm, and all the templates that use it under control of that application.cfm get the benefit of the change).
However, there's a problem and it can be a nasty one. This issue has to do with the locking of (or failure to lock) shared-scope variables such as this one, and the fact that rarely does any discussion of this approach include the consequences of using shared variable scopes. There have been other articles in CFDJ on the subject of shared variable locking, as well as Macromedia Knowledge Base articles.
Maybe you didn't make the connection between them and this issue. This article puts the problem in perspective and offers some explanations of how to understand and resolve it. The ultimate solution involves using a "request"-scoped variable instead of an "application"-scoped one.
If you're not familiar with shared variable scopes, or are fuzzy about locking issues, or perhaps have never understood what "request" scope variables are about, this article should help you.
If you do understand these things, change your references to application.dsn to request.dsn, and if you find any locks around code that was using such an application.dsn variable, you need to consider whether those should stay as well. I'll also offer insights into how to find and fix such locking references.
You may see code doing this in application.cfm:
<CFSET application.dsn = "whatever">
which declares the variable as "global," in essence, and can therefore be used later in all other templates as in:
<CFQUERY datasource="#application.dsn#" ... >
to refer to that data source name. The upside to this is that if the data source name needs to be changed (from "whatever" to "whatever_test", for instance), you can simply modify the application.cfm to point to the new name, and all templates under its control get the benefit of the change.
It's a good plan, but the use of an application-scoped variable is flawed. It opens you to potentially troublesome locking issues (for more on that, including a good explanation for why it's a problem, see "ColdFusion Locking Best Practices" at www.allaire.com/Handlers/index.cfm?ID=20370&Method=Full). More important, you can have the intended benefit with an equally useful and less troublesome way.
For reasons I'll explain in a moment if it's still unclear, I'm suggesting that you stop using the application scope to hold the data source name. However, instead of dropping "application." from the variable name, I'm suggesting that you use the "request" scope. In other words, do the following (in your application.cfm):
<CFSET request.dsn = "whatever">
and then in all your templates do:
<CFQUERY datasource="#request.dsn#" ...>
If it's not clear why this is useful, or how it works, then there may be confusion about:
- How the application.cfm works like a CFINCLUDE (and how we could, but won't, use a local variable called "dsn")
- What the request scope is about (and why it's better to use "request.dsn")
How Application.cfm Works Like a CFINCLUDE
And How We Could, but Won't, Use a Local Variable Called "dsn"
Nearly every CF developer knows that whenever a CF template is run, CF first tries to execute any application.cfm that exists in the same directory (or its parent directory, or its grandparent, and so on).
What may not be obvious is that CF actually runs the application.cfm like a CFINCLUDE, which means that any variables set there, including "local" variables (such as <CFSET firstname="bob">), are then available to the template that was originally being run.
So let's say we have a template that does the following:
If it did this and nothing else, you might expect it to fail since you can't refer to variables that don't exist, and it's only outputting the variable, not creating it. But if firstname was set in application.cfm (assuming this template is in a directory controlled by that application.cfm), it can indeed refer to the variable.
Knowing that, you may wonder why the folks who promoted this solution of setting the dsn variable to the application scope even bothered. They could just as easily have said:
<CFSET dsn = "whatever">
and then in all their templates do:
<CFQUERY datasource="#dsn#" ...>
It would work. In fact, there's no need to be using the application scope to pass the variable to all templates (make it global), because any variables set in the application.cfm "trickle down" to all templates, in effect making them global. There are certainly good uses of application scoped variables, but this isn't one of them.
The simple example of setting a variable called "dsn" (or what could be formally specified as variables.dsn, which is the same thing) to hold the name of the data source would work, and would trickle down to all the templates. It's effectively "global," at least for the life of that template, and it's reset at the execution of each template by being executed in the application.cfm each time.
I've recommended that you use "request.dsn" rather than "dsn" or "variables.dsn". Why? And what is the request scope, anyway?
What the Request Scope Is About
And Why It's Better to Use "Request.dsn"
If you understand that setting a local variable called "dsn" will work, can you think of any situation in which your code may expect to have access to that variable but won't? Think hard. Okay, custom tags. Yep, most know that custom tags have their own local variable scope. So a local variable set in the caller (or in the application.cfm) won't be available to the custom tag.
When we were setting the dsn variable to an application scope, it was available in the custom tag (as are all shared scopes and also form, url, cgi, and other variables that are passed to the calling template).
By changing the application.dsn variable to dsn (or variables.dsn, same thing) while it's available in all templates under control of the application.cfm, it's not available to any custom tags called by those templates. That's why we need to use the request scope instead.
Its sole purpose, poorly understood though it is, is to create local variables in a program that are available within custom tags called by that program (and vice versa). That's it. Nothing more.
Many confuse the request scope with some sort of persistence or shared nature (and the fact that there's a different kind of "request" scope in other languages like ASP and JSP only confuses matters further). It's best to think of it as nothing more than a scope that allows local variables to be seen in a custom tag called by the template setting the request scope variable. And since our request.dsn variable is set in the application.cfm, it trickles down to the template being executed and is therefore also available to any custom tags we call as well.
That's why you should use the request scope rather than a local scope.
Remediation of Application.dsn Misuse
One last thought: you may not be able to blindly do a global search and replace application.dsn with request.dsn wherever it occurs. Depending on the savvy of the coder, the use of application.dsn may have at least two wrinkles that require more care than just replacing application.dsn with request.dsn:
- You may be testing for the existence of application.dsn before setting it in the application.cfm, in which case you need to set the request.dsn outside that test since it will never "already exist."
- You may have CFLOCKs surrounding CFQUERYs, or CFLOCKs that are moving the application.dsn to a local variable. You wouldn't want to just rename the scope in those instances.
I hope this article not only helps prevent problems with application.dsn, specifically, but also increases your understanding of request scope variables and application.cfm processing in general.
|charlie arehart 04/15/08 02:16:10 PM EDT|
Thanks for that, Brian. I should add that while this article was from 2001, since CF7 we now have application.cfc and its onapplicationstart method. That does change things a bit, in that one could safely create an application variable there and it really would be created only once, at the start of the application. For that reason, I suppose it may no longer be so "wrong" to see application.dsn--but again, that's only if you're using this feature. Otherwise, it may be better to stick with the request scope as discussed in the article.
|Brian 04/04/08 03:17:23 PM EDT|
Very informative! I've been wondering what the request scope is for such a long time and no other resource did such a great job of explaining it.
|Charlie Arehart 08/31/01 10:36:00 AM EDT|
A read asked by email: "don't you also need to lock request vars?" The answer is no. They're not shared by any other user. More particularly, they're not shared by any other "thread".
The request scope, like the variables scope, is local to the running program and belongs only to it. It's a single thread of execution, so there's no risk of conflict with other threads, as with the "shared scope" variables, server, application, and session.
- Where Are RIA Technologies Headed in 2008?
- The Next Programming Models, RIAs and Composite Applications
- AJAX World RIA Conference & Expo Kicks Off in New York City
- Constructing an Application with Flash Forms from the Ground Up
- Building a Zip Code Proximity Search with ColdFusion
- Personal Branding Checklist
- CFEclipse: The Developer's IDE, Eclipse For ColdFusion
- Has the Technology Bounceback Begun?
- Adobe Flex 2: Advanced DataGrid
- i-Technology Viewpoint: We Need Not More Frameworks, But Better Programmers
- Web Services Using ColdFusion and Apache CXF
- Passing Parameters to Flex That Works