Re: [CFCDev] Slightly OT - Is Thread Safe

[Peter J. Farrell]

Spike et All,
Since the "local" instantiation of the object is var'ed - Wouldn't that object be 
available only to the method that was called and only for the duration of that instance of 
uploadFile?  Or am I missing something here?
BarneyB's Ex:
myService.cfc
<cfcomponent>
<cffunction name="uploadFile">
  <cfargument name="filename" />
  <cfset var ftper = createObject("component", "ftper") />
  <cfset ftper.init(...) />
  <cfset ftper.uploadFile(filename) />
</cffunction>
</cfcomponent>
ftper.cfc
<cfcomponent>
<cffunction name="uploadFile">
  <cfargument name="filename" />
  <cfftp ... />
</cffunction>
</cfcomponent>

Spike wrote:
Are you sure about this?
As far as I remember, CFFILE is a global scope like URL, FORM, or REQUEST. I
don't think you can avoid concurrency by creating a one-time-use CFC. It's
been a while since I ran the tests, but I seem to remember that if you use a
CFC to perform file operations such as upload, you can access the cffile
scope from the calling page. I think that would indicate that the approach
you suggest below won't be thread safe.
For CFFILE the only way I know to make it thread safe is to lock the access,
then take a duplicate of the CFFILE scope before closing the lock.
I don't know about any of the other scopes Peter asked about though.
Spike
--------------------------------------------
Stephen Milligan
Code poet for hire
http://www.spike.org.uk
Do you cfeclipse? http://cfeclipse.tigris.org 

 

Your application-scope CFC would have a method that simply
instantiated a CFC into a local variable, and then called a method on
it.  That method on the new CFC would house the problematic tag,
rather than having it directly inside the application-scoped CFC's
method.  Since every invocation of the method would generate a new
one-time-use CFC, you'd avoid any concurrency issues.
Right now:
myService.cfc
<cfcomponent>
<cffunction name="uploadFile">
  <cfargument name="filename" />
  <cfftp ... />
</cffunction>
</cfcomponent>
The new way:
myService.cfc
<cfcomponent>
<cffunction name="uploadFile">
  <cfargument name="filename" />
  <cfset var ftper = createObject("component", "ftper") />
  <cfset ftper.init(...) />
  <cfset ftper.uploadFile(filename) />
</cffunction>
</cfcomponent>
ftper.cfc
<cfcomponent>
<cffunction name="uploadFile">
  <cfargument name="filename" />
  <cfftp ... />
</cffunction>
</cfcomponent>
cheers,
barneyb
On Tue, 10 Aug 2004 11:50:34 -0400, Peter J. Farrell
<[EMAIL PROTECTED]> wrote:
   

No way am I forking threads here.  But my CFCs are application-scope,
except in one - I need to use CFPOP and CFFILE.  I'm was wondering if
those tags were thread safe.
According to Sean and the link to his blog entry:
You can "trick" by var'ing their own result "scopes" (i.e. cfcatch
returns cfcatch.XXX):
CFCatch
CFHTTP
You cannot trick with a var:
CFFile
CFQuery (cfquery.executiontime - but who uses this really?)
Now, what about the following that also return their own 
     

result "scope":
   

CFPop
CFStoredProc
CFFTP
CFDirectory
CFSearch
CFError
Which of these can you trick with a var of their result 
     

"scope"?  Anyone
   

know before I go crazy and try to figure it out.
And if you have to create move your CFC that uses the ones that you
cannot trick - how do you go about creating this per-request CFC.
Meaning, I would want to instantiate it every request, only 
     

on the ones
   

that use it.  It looks like I'm going to need to make some type of
controller here to check if a per-request CFC exists and if 
     

it doesn't
   

create it.
..peter
     

----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' 
in the message of the email.

CFCDev is run by CFCZone (www.cfczone.org) and supported
by Mindtool, Corporation (www.mindtool.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' 
in the message of the email.

CFCDev is run by CFCZone (www.cfczone.org) and supported
by Mindtool, Corporation (www.mindtool.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' 
in the message of the email.

CFCDev is run by CFCZone (www.cfczone.org) and supported
by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]