Re: [CFCDev] Best Practices Question, Where to Instantiate a CFC

[Nando]

I'm not sure you'd need that double locking for session scoped variables, but you do need it for application or server scoped variables if you want to ensure that there is only one instance of that CFC. Here's why, with another code example using application scope. <cfif not structKeyExists(application,"MyCFC")>     <cfset application.myCFC = createObject("component","MyCFC").init() /> </cfif> Say user A hits the above code block without the double "not structKeyExists()" test, and there's not an instance of application.myCFC at that time. They would pass the if "not structKeyExists()" test. Say another user, B, hits that code block "a few milliseconds" later, before the object was created. User B would also pass the "not structKeyExists()" test, and i've heard it said that you can then get 2 instances of the CFC. What i'm not exactly clear on is the consequences of that. Apparently, user A has a pointer to an application scoped CFC that would last for the duration of user A's initial request. On user A's next request, presumably application.myCFC would point to the instance that user B created, and the instance that user A created would be floating in space unused, perhaps taking up memory needlessly until the application expired. There might be other consequences to your application, depending on what that CFC does. Perhaps someone else is more clear on the consequences. Hence the double test locking code is recommended as best practice: <cfif not structKeyExists(application,"MyCFC")>       <cflock name="MyCFCLock" type="exclusive" timeout="10">           <cfif not structKeyExists(application,"MyCFC")>               <cfset application.MyCFC = createObject("component","MyCFC").init() />           </cfif>       </cflock>  </cfif> BUT for session scoped variables, it's usually impossible for a single user to hit an "if not structKeyExists(session,"MyCFC") code block twice within the same request, much less hitting it twice within "a few milliseconds". If you're using frames in such a way that makes that possible, then yes, the double locking might be necessary. Otherwise, for session scoped variables, it's generally not needed. A single test will suffice. ciao, Nando Lyons, Larry wrote: Thanks all. I figured that the app scope would be best for this CFC but I wanted to be sure.   Dan, one question about the code you included, is there any reason why you checked for the existence of the session.FormStateManager both outside and inside the cflock? With the first cfif, you already have tested for its existence.   thx, larry -----Original Message----- From: Daniel Roberts [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 19, 2006 9:52 AM To: CFCDev@cfczone.org Subject: Re: [CFCDev] Best Practices Question, Where to Instantiate a CFC Here's the code I use for setting up an object into a shared scope. I believe I got it out of one of Sean Corfield demo apps.     <cfif not structKeyExists(session,"FormStateManager")>         <cflock name="FormStateManager" type="exclusive" timeout="10">             <cfif not structKeyExists(session,"FormStateManager")>                 <cfset session.FormStateManager = createObject("component","extensions.components.FormStateManager ").init() />             </cfif>         </cflock>     </cfif> On 4/19/06, Daniel Roberts < [EMAIL PROTECTED]> wrote: sounds like a perfect candidate for applications scope 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 cfcdev@cfczone.org 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/cfcdev@cfczone.org ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org 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 cfcdev@cfczone.org 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/cfcdev@cfczone.org