A CF 8 Race Condition to Avoid
I recently stumbled across a scenario in which what appears to be the most flexible way to write some code ends-up introducing a somewhat nasty race condition that breaks your ColdFusion 8 application. In Application.cfc you can specify application settings such as session behavior and the application name - in CF 8 you can also specify application specific custom tag paths.
It's not uncommon for a company to have a template or template files that they use when creating new applications - these "skeleton files" often contain common or "generic starting point" code that you then build upon. We have a core CFC code base that requires a mapping to use easily across every application... so I thought it made an awful lot of sense to have something like the following in our "skeleton" Application.cfc file for defining each application:
Note that each application can set their custom tag path to whatever they want, and the code in the skeleton file will always append the path to our core code base to the custom tag path. Makes a lot of sense, except for one small problem: this code exists outside all of the server event handler methods, so it runs on every request. For the brief period of time between when a request runs the line of code that initializes the custom tag path and the line of code that appends the core library path to the custom tag path, any code that executes for any user that requires the path to the core code library to be in the tag path will fail.
The CFCs in the core library, as you'd imagine, are used in several server event handler methods including the onApplicationStart() and onSessionStart() methods - so the core library must be added to the custom tag path in this script block outside the event handler methods. If you don't believe me, try hitting an app. that appends to the tag path in this manner with some load. If you have long-running code blocks that rely on the mapping you will, of course, find it much easier to see the errors get generated.
So the moral of the story is, if you want to be safe, do not append to the custom tag path in your Application.cfc files - like the infommercial says, just "set it and forget it".
It's not uncommon for a company to have a template or template files that they use when creating new applications - these "skeleton files" often contain common or "generic starting point" code that you then build upon. We have a core CFC code base that requires a mapping to use easily across every application... so I thought it made an awful lot of sense to have something like the following in our "skeleton" Application.cfc file for defining each application:
<cfscript>
// change per app
this.name = '[your_app_name_here]';
this.sessionManagement = true;
this.sessionTimeOut = createTimeSpan(0,0,20,0);
// change per app (add paths)
this.customTagPaths = '';
this.customTagPaths = listAppend(this.customTagPaths, expandPath('path-to-our-code-library'));
</cfscript>
// change per app
this.name = '[your_app_name_here]';
this.sessionManagement = true;
this.sessionTimeOut = createTimeSpan(0,0,20,0);
// change per app (add paths)
this.customTagPaths = '';
this.customTagPaths = listAppend(this.customTagPaths, expandPath('path-to-our-code-library'));
</cfscript>
Note that each application can set their custom tag path to whatever they want, and the code in the skeleton file will always append the path to our core code base to the custom tag path. Makes a lot of sense, except for one small problem: this code exists outside all of the server event handler methods, so it runs on every request. For the brief period of time between when a request runs the line of code that initializes the custom tag path and the line of code that appends the core library path to the custom tag path, any code that executes for any user that requires the path to the core code library to be in the tag path will fail.
The CFCs in the core library, as you'd imagine, are used in several server event handler methods including the onApplicationStart() and onSessionStart() methods - so the core library must be added to the custom tag path in this script block outside the event handler methods. If you don't believe me, try hitting an app. that appends to the tag path in this manner with some load. If you have long-running code blocks that rely on the mapping you will, of course, find it much easier to see the errors get generated.
So the moral of the story is, if you want to be safe, do not append to the custom tag path in your Application.cfc files - like the infommercial says, just "set it and forget it".
There are no comments for this entry.
[Add Comment]