Ok, thanks for the replies. I'll rework it to explicitly instantiate into the local var scope within each function. I have no feeling as to whether this has a lot of overhead with it; does it? Is there any way to reduce that overhead or streamline the dispatching of beans? I do like the idea of using bean type objects to pass data between layers, its given me a bit more flexibility and cleaner code than my previous methods of passing structs back and forth (still do that sometimes as well), and with having to instantiate within each and every function that passes data this will mean a lot of createObject calls to create the beans. Any thoughts on that?
Kevin > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Roland Collins > Sent: Friday, September 24, 2004 8:57 PM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] Testing Thread Safety > > > <cfset var transfer = ""> > <cfset transfer = variables.transferBean> > > The above is definitely not thread safe - all you're doing is > assigning a reference to the object, not making a copy. > > Unfortunately, duplicate() does not return a deep copy of > CFCs - this is a known bug. Actually, if you haven't applied > the latest CFMX updater, duplicate doesn't really duplicate > much (see the link below). Even _with_ this hotfix, however, > duplicate does not really create deep copies of CFCs - it's > still just returning your original reference. The ONLY way > to make this thread-safe is to recreate your object each > time. You _have_ to recreate it at the top of each function: > > <cfcomponent> > <cffunction name="someProcess" returntype="transferBean"> > <cfset var transfer= createobject("component","transferBean")> > <cfset transfer.setValue(result from something)> > <cfreturn transfer> > </cffunction> > </cfcomponent> > > > Here's the details on duplicate: > http://www.macromedia.com/support/coldfusion/ts/documents/dupl > icate_hotfix.h > tm > > Roland > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Kevin J. Miller > Sent: Friday, September 24, 2004 1:55 PM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] Testing Thread Safety > > Roland, > > Then based on your reply to a subsequent mail, were I to do: > > <cfset var transfer = ""> > <cfset transfer = variables.transferBean> > > This would or would not be thread safe? > > Could I do: > > <cfset transfer = duplicate(variables.transferBean)> this > being a deep copy and not passing by reference. > > ? > > Kevin > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Roland Collins > > Sent: Friday, September 24, 2004 6:17 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [CFCDev] Testing Thread Safety > > > > > > This usage of var is _not_ helping with thread safety because > > you're only using it to avoid having to qualify your with the > > variables scope. Var only helps with thread safety when it > > is the original instantiation of the variable - all you are > > doing is referencing an existing shared object. Your code is > > functionally equivalent to skipping the var statement > > entirely and just writing the follwing: > > > > <cfset variables.transferBean = > > createobject("component","transferBean")> > > > > <cffunction name="someProcess" returntype="transferBean"> > > <cfset variables.transfer.setValue(result from something)> > > <cfreturn variables.transfer> > > </cffunction> > > > > This is not thread safe. If two threads call someProcess at > > the same time, there is the potential for transfer.setValue > > to be called twice before the cfreturn statements get executed. > > > > Roland > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Kevin J. Miller > > Sent: Friday, September 24, 2004 10:33 AM > > To: [EMAIL PROTECTED] > > Subject: RE: [CFCDev] Testing Thread Safety > > > > What do you see is the danger there, that an update to the > > local transfer variable would update the > > variables.transferBean original object? I don't see how > > that's possible, given that it has been scoped locally > > (regardless of passing by reference). Ultimately, this is > > the precise issue I'm trying to clarify. But what you're > > saying is that *this* usage of local scoped vars is NOT > > thread safe? Can that be true? > > > > Kevin > > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > > > Behalf Of David Ross > > > Sent: Friday, September 24, 2004 4:12 PM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [CFCDev] Testing Thread Safety > > > > > > > > > I'd say that's NOT thread safe, as the local var is only > a pointer > > > to the variables instance. Two simultaneous requests will > both have > > > separate variables, but since they're both pointing at the same > > > thing, it won't make a difference. You need to instantiate your > > > transfer bean component into the local var "scope". > > > > > > -Dave > > > > > > >>> [EMAIL PROTECTED] 9/24/2004 7:16:09 AM >>> > > > > > > > > > > > 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 > > > ---------------------------------------------------------- > > > 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] > > > ---------------------------------------------------------- > 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]
