If you have empirical evidence, are you (Jay) running 6.1 or 6.0? Kind of off topic, but we had problems with local variables getting overwritten in shared scope CFCs on 6.0, but they seemed to have gone away with 6.1.
The particular code in question was this (with bogus names): 1 <cffunction> 2 <cfset var getStuff = "" /> 3 <cfset var getOtherStuff = "" /> 4 <!--- the app runs MySQL, so no subselect ---> 5 <cfquery name="getStuff"> 6 SELECT ... 7 </cfquery> 8 <cfquery name="getOtherStuff"> 9 SELECT ... 10 WHERE colName IN (#valueList(getStuff.col)#) 11 </cfquery> 12 <cfreturn valueList(....) /> 13 </cffunction> Sometimes the value of getStuff at line 10 would be the empty string, obviously creating problems. The only solution we found was to put the method call in a CFLOOP with a CFTRY..CFCATCH around it, and if it errored, just keep calling it until it worked. We used someone's (Nathan D?) little sleep function to add a couple hundred milliseconds of wait in there as well. Horrible, but fixed in 6.1. barneyb > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Sean A Corfield > Sent: Wednesday, November 12, 2003 9:32 AM > To: [EMAIL PROTECTED] > Subject: Re: [CFCDev] Native CF tags and local scope > > > On Thursday, Nov 6, 2003, at 11:48 US/Pacific, Jay Gibb wrote: > > In my previous example, if multiple requests were using the component > > in a persistent scope (like Application.myCFC or whatever) it would > > cause > > problems if more than one request happened to get into that > > <cfcatch></cfcatch> simultaneously. > > Is this supposition or do you have empirical evidence that this is, in > fact, the case? I ask because we use exception handling heavily in CFCs > that are stored in shared scopes and we have not experienced the > problems you seem to be talking about. > > > Without 'var' scoping the cfcatch > > structure, I'm running a really good possibility that one request will > > get > > the cfcatch structure generated by someone else. > > I don't believe that is the case (but I can check with the product > team). It seems to me the cfcatch structure would have to be unique to > each request - otherwise people would be tripping over that issue all > the time (and would have seen it in pre-MX versions of CF as well!). > > > This is one more reason not to use CFCs for anything more than a code > > organization tool for a procedural system. I can't help but think > > that it > > was slapped together by Macromedia as an after-thought. > > CFCs went through a lot of design iterations and were honed throughout > the entire MX lifecycle to reach where they are today. I'd hardly call > that "slapped together". macromedia.com uses CFCs heavily and the team > that built the apps has a lot of hardcore Java and C++ background so > they understand OO and design patterns pretty well. They're pretty > happy with CFCs. Mach II is another example of using CFCs to > successfully build OO software (and we're adopting Mach II at > Macromedia - hear me talk about our experiences at BACFUG in December > and - in more detail - at MXDU in February). > > If you don't think CFCs are worthwhile, fair enough, but I think you > need to look again... > > Sean A Corfield -- Director, Architecture > Web Technology Group -- Macromedia, Inc. > tel: (415) 252-2287 -- cell: (415) 717-8473 > aim/iChat: seancorfield -- http://www.macromedia.com > An Architect's View -- http://www.macromedia.com/go/arch_blog > > MAX, the 2003 Macromedia User Conference > November 18-21, Salt Lake City, Utah > Register today at http://www.macromedia.com/go/max > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the word '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 word '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]
