Todd had an interesting question regarding the user of the server scope:
I was thinking that rather than invoking a common employee information cfc object into the application scope (with multiple other applications doing the same thing), it seemed like a good idea to just invoke it into the server scope.Interestingly enough - I can't honestly remember the last time I used the server scope. Maybe because a lot of (almost all of) my development is for applications, and not a complete "dot com", I tend to shy away from the scope as I never know who else may be rummaging around in there. Even if you plan on developing on your own box and serving on a box you own, I'd still be concerned about the possibility of having to share a box with others. (Of course, if the box uses multiple instances of ColdFusion, then it isn't really an issue.)Follow-up question: If this were done and an update was made to the employee.cfc, would that change get overwritten in server memory?
So at a basic level - I guess this makes sense. Again - if you are sure you are the only one on the box. CFC creation can be a bit slow, so if the multiple applications could all share the same resource, I could see that being helpful. Of course, you want to watch out for possible race conditions.
With this said though - I still feel uneasy about recommending this. Am I an old fuddy duddy or do others agree?
As for his follow up question, if server.foo was an instance of foo.cfc, and you edited foo.cfc, the server instance would not be updated. You would need to create a routine to create it again. Typically I add url "hooks" to my applications that force the recreation of Application-scoped CFCs. There is nothing preventing you from doing the same with server scoped variables.
Archived Comments
I could see this working in a corporate / intranet setting. Where I work we have several employee lookup functions and I'm sure each and every application on our servers has an instance of that firing off. Seems like that would be perfect for the server scope.
I work at a dot-com where we run several different finance sites on the same CPU. They all refer to certain common information (such as U.S. federal and state tax rates, for example.) In that instance, we use the server scope since it's more efficient than duplicating the information in each application. That being said, that information hardly ever changes, so we don't worry about race conditions.
Unfortunately you need to be aware of it's use in some third party code. eg: FCKeditor's CF filebrowser used (just checked, still does in 2.4.2 release) a SERVER var for the filepath in it's backwards compatibility checks. I ran into an issue recently where a modified version we deployed to a local government server had it's userFilesPath hijacked by the backwards compatibility stuff as there was another FCKeditor instance running in an older application elsewhere on the system. Thought I was going nuts initially!
To me the question would be what are the risks versus what the gains are from doing this. I would think the only way you could claim you gain much from using the server scope would be that you're running each application in it's own instance or that you've actually taken the time to ensure that the employee object is more or less exactly the same for every application. Now if you're running multiple instances of CF you don't risk the cross over. But at that point isn't the server scope essentially the application scope? And if you're not doing that, I have a hard time believing that you can assume that the employee object is and will continue to be the same for all applications. And even if it is, are all the business rules involving it going to be the same? I can see where we may see "employee.cfc" in 4 different applications but I'd be cautious about it since while they're the same in name, they may be different in practice.
I tend not to use the server scope either -- I don't think that general "policy" is fuddy-duddy, I think it is good practice. The simple fact of the matter is that "you" don't have control over the scope. Even in corporate environments where "you" do, are you really the only one coding on the box? Even if that is the case, do you want to add that layer of dependency into your code? Are you going to flesh out a system to ensure the server scope vars are maintained properly? What if your system goes from a single-server environment to a multi-server environment...?
I think the motivation is quite understandable and I certainly wouldn't consider the approach "wrong"...just not the one I would probably choose given the implications. I think in general I'd be more apt to create a web service that provides that information to multiple applications (or perhaps even more likely, just let all the apps do the work).
Also, in general, that is one of the last types of optimization I'd be looking at...I'd only consider the additional "complexity" of that type of optimization if my app was still not meeting performance requirements and I had exhausted the myriad of other options available to me.
I wanted to say thank you for the comments. This has been very helpful and raised some points I hadn't considered. I really appreciate it.