Thanks for the response.  If you don’t mind, let me post here what I eventually did.  I’m open to any thoughts, but I think it is relatively close to what you are suggesting.  The only thought that nags at me is that a component shouldn’t necessarily know what scope it is in. So if it is possibly going to be in a shared scope, then should we lock all methods that write instance data?

 

Anyway, here is what I did.

 

In the init method, I set the name:

                        <cfset local.lockname="bloggerlock">

                        <cflock name="#local.lockname#" type="exclusive" throwontimeout="true" timeout="10">

                                    <cfset instance=structnew()>

                                    <cfset instance.lockname=local.lockname>

                        </cflock>

 

Then  in all the methods that had a <cfset instance.* = >

I wrapped it in the same lock

                        <cflock name="#local.lockname#" type="exclusive" throwontimeout="true" timeout="10">

                                    <cfset instance.foo=bar>

                        </cflock>

 

 


From: Brian Kotek [mailto:[EMAIL PROTECTED]
Sent: Monday, December 05, 2005 12:37 PM
To: [email protected]
Subject: Re: [CFCDev] Locking Instance data in applicaiton scoped CFC

 

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]

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