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 MaePub
David Ross wrote:
no one is forking off threads... thread safety is necessary because (especially in mach-ii's case) many CFC's are application-scoped, so any request is using the same instance of that CFC. CFC's need to be thread safe because the server will simultaneously process many requests at a time, and if multiple requests hit the same cffunction on the same cfc instance at the same time, they need to have their own set of function-local variables (hence the need to "var" everything, even iterators and query names).
-Dave
----------------------------------------------------------
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]
