> > I am not "positive"... but doesn't a object (like a CFC) get > passed by ref? Does it recreate transferBean in var scope as > transfer... or does transfer just get assigned the reference > of the object... allowing both variables to address the same object?
This is exactly the question. I can and will test it of course, but I was wondering if it was a known behavior one way or the other. With all the hooha about local scoping vars in functions, I would presume that doing the <cfset var transfer = variables.transferBean> WOULD be ok. Thought the braintrust would have an answer on this. Kevin > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Kevin J. Miller > Sent: Friday, September 24, 2004 3:15 AM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] Testing Thread Safety > > Yes, that's precisely what I'm doing and I do try to var > everything. Typically within functions I'll declare a <cfset > var local = structnew()> and try to work within IT for most > of the vars, as appopriate, so I have an easy envelope for > things like loopcounters, e.g. local.i and so on. I also > declare a <cfset var q = structnew()> and use that > exclusively for cfquery and cfstoredproc resultset names. > > Anyway, my real question though was regarding how I showed I > was utilizing the transferBean. It is declared in the > constructor of the CFC ('once') and is used to move data back > and forth between components; in the functions I do <cfset > var transfer = variables.transferBean> in order to get a > local scoped copy, leaving the constructor copy intact, > waiting for more requests to copy to a functions local scope. > Is this sound? I think it is, but I'm not sure what the > ramifications of passing by reference are in regards to > thread safety. This particular bean cfc is just an object > where I store result data and errors when making calls from > one cfc to the other, so its used A LOT. I use a similar > approach with session userBeans. Does this sound ok? > > Just to restate in code: > > <cfcomponent> > <cfset transferBean = createobject("component","transferBean")> > > <cffunction name="someProcess" returntype="transferBean"> > <cfset var transfer = transferBean> > > <cfset transfer.setValue(result from something)> > > <cfreturn transfer> > </cffunction> > </cfcomponent> > > > Thanks, > Kevin > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Barry L Beattie > > Sent: Friday, September 24, 2004 7:39 AM > > To: [EMAIL PROTECTED] > > Subject: Re: [CFCDev] Testing Thread Safety > > > > > > > > hang on, aren't you decorating your object with functionality > > from common, error, transferBean? > > > > <cfcomponent> > > > > <!--- include a copy of the common cfc functions here ---> > > <cfset common = createobject("component","common")> > > <cfset error = createobject("component","error")> > > <cfset transferBean = > > createobject("component","transferBean")><!--- > > this is a cfc used for moving return values between cfc's ---> > > > > so if this component was in application scope, the others > > would be part of the same memory space? and if you var'd > > everything (like people are suggesting - even to the point of > > <cfset var qry = queryNew("") />...) and checked for race > > conditions when working with instance data within the CFC... > > > > ...what else could go wrong? > > > > I ask because I do this all the time and I'd welcome being > > corrected if I've FooBar'd anything... > > > > thanx > > barry.b > > > > > > > > > > > > > > -- > > ___________________________________________________________ > > Sign-up for Ads Free at Mail.com > http://promo.mail.com/adsfreejump.htm > > > > ---------------------------------------------------------- > > 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] > ---------------------------------------------------------- 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]
