Hi Gerry, nice to see a fellow NIEHS'er on the list.

If the CFC that you are placing in the application scope is stateful, then yes you'll need to lock the WRITES to the variables scope to avoid race conditions. I do this by creating a UUID in my init() method and using that as the lock name. This way a globally-unique ID will exist for the life of the CFC instance, and by using that ID as your lock name, you can avoid having to lock the entire application scope. Per method lock names might also work if you are positive that the only place that particular instance variable is written to is in that method. But I think that would require more diligence on the part of the developer.

Hope that helps,

Brian Kotek

On 12/4/05, Gurevich, Gerry (NIH/NIEHS) <[EMAIL PROTECTED]> wrote:
How do you handle locking of instance data in an application scoped CFC?
 
The CFC shouldn't care what scope it is called in, but I have one that will ALWAYS be in the application scope. When setting the instance data, should I lock the entire call?  I have some very time consuming calculations that need to occur before assigning the data to the instance scope. I suppose I could perform the calculations in one method call and then lock a subsequent method call to set the data.  But the lock, I'm thinking should be outside the call not inside the method.
 
ON the other hand, if I use a named lock it doesn't matter, does it.  I'm just thinking out loud here and was wondering what others do.  Dose this make sense?
 
Here's some pseudo code:
 
component name="appscopedcfc"
 
function1
    do some complicated stuff and return a structure of values
 
fucnction2
    <cflock name=function2lock>
        <cfset some instance values>
    </lock>
 
code
 
    getstuff=application.objappscopedcfc.function1();
   application.objappscopedcfc.function2(getstuff);
----------------------------------------------------------
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]

----------------------------------------------------------
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]

Reply via email to