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]
