In my opinion, if it is just a set of util functions, with no data held inside it, what you basically have is a service. If it is shared and the same for every session, you should create it in the application scope on application startup. Then you just have to call application.mycfc.myfunction() whenever you need it. That should work fine across clusters as well. Only if it is a different cfc for each session, meaning it has instance data that changes based on session should you store it in the session scope, and only if it changes with every request should you store it in the variables or request scopes. Sounds to me like a prime canidate for the application scope. Just make sure that you are only creating it if it is not already created or if you explicitly want it to reload.
On 4/19/06, Lyons, Larry <[EMAIL PROTECTED]> wrote: > I put this on the CF-Talk list, but thought that given the signal to noise > ratio there, and the focus of this list, I thought I'd try here as well. I'm > trying to get a feel for what's a best practice when instantiating a CFC. > > I have a site that uses one CFC a fair amount. Eventually I'll be moving > this site to a clustered environment, so serialization may be a concern. > However, there is no data within the cfc, just a set of functions. All data > is passed in, manipulated etc, then returned to the calling page. > > What would be better in this case, keeping the cfc in the variables scope or > moving it to either the application or session scopes? > > many thanks, > > larry > > -- > Larry C. Lyons > Web Analyst > BEI Resources > American Type Culture Collection > http://www.beiresources.org > email: llyons(at)atcc(dot)org > tel: 703.365.2700.2678 > -- > > > This electronic communication, together with any attachments, may contain > information that is legally privileged, confidential or otherwise private. > The information is intended only for the use of the individual or entity to > which it is addressed. If you are not the intended recipient, please be > aware that any disclosure, copying, distribution or use of the contents of > this communication or any attachment is strictly prohibited. If you have > received this communication in error, please immediately notify the original > sender and delete the received information from your system. Thank you. > > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email to > [email protected] with the words 'unsubscribe cfcdev' as the subject of the > email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting > (www.cfxhosting.com). > > An archive of the CFCDev list is available at > www.mail-archive.com/[email protected] > > > -- Ryan Guill A Deep Blue [EMAIL PROTECTED] www.ryanguill.com (270) 217.2399 got google talk? Chat me at [EMAIL PROTECTED] The Coldfusion Open Application Library - COAL - http://coal.ryanguill.com Use CF and SQL? Try qBrowser - http://www.ryanguill.com/docs/ www.ryanguill.com/ The Roman Empire: www.ryanguill.com/blog/ ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
