Since that is the way most of us are doing it, I would suggest doing it also until a clear answer comes out.
But I thought the experiment that Nathan did and that I extended showed that using var to localize the cfquery return variable did nothing -- that the returned values are dumped into Variables.cfquery and not the local var'd cfquery. Therefore using var to isolate these values when your cfc is persistent won't help; it may be worse than doing nothing since you may begin coding as if race conditions have been taken care of.
It seems that if you need to eliminate race conditions for accessing these values then you need to:
1) use a named cflock, where the name is used everywhere that can create variables in the same Variables scope (i.e., all cfquery tags in the same cfc)
2) immediately after your </cfquery> you dump the cfquery values into a var'd variable (using dublicate() I assume)
It's not enough to uniquely name the cflock for the one cfquery that you want to preserve, since any other query in the same cfc will overwrite the cfquery value, even if the one you do want to preserve is inside a lock. I plan on using a name of cfcname_variablename to make sure each method uses the same lock.
I have not extended this experiment to see if other return variables (cffile, cfftp, etc.) follow the same pattern.
--
Ben Curtis
WebSciences International
http://www.websciences.org/
v: 310 478 6648
f: 310 235 2067----------------------------------------------------------
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]
