So is the question your asking..If you have an instance of a component instantiated and set in the application scope, and two threads/people call the very same function in that object, will one request interfere with the local variables of the other request?
I have yet to test this, however I would assume so, considering the objects properties and methods reside in memory(application). However... to err is human.. So I could be wrong! -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark M Sent: Tuesday, 1 June 2004 1:04 PM To: CFAussie Mailing List Subject: [cfaussie] RE: Odd Scope / Locking Question Stephen! ;o) Please read what I write. > The CFC is *not* changing specific application scope data - i.e. there is *not* a > > > application.myCFC = createObject(...); > application.myStruct = new Struct(); > > and the myCFC is tinkering with the myStruct scope. Let me please repeat - this is NOT happening. NOT NOT NOT. It's local data to the CFC instance it's manipulating (i.e. variables scope) Mark ------------------------------------------------------------------ [EMAIL PROTECTED] ICQ: 3094740 Safe From Bees [ www.safefrombees.com ] Quoting Stephen Bosworth <[EMAIL PROTECTED]>: > What should be happening here is that application.myStruct should not be > tinkered directly within your CFC. You should be passing it as an argument > to your CFC method > > > application.myCFC = createObject(...); > > application.myStruct = new Struct(); > > <cfset myComp = CreateObject("component","path.to.mycomp") /> > > <cflock name="test" timeout="10" type="exclusive" throwontimeout="yes"> > > <cfset application.myStruct = > myComp.tinkerWithAppStruct(application.myStruct) /> > > </cflock> > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Stephen Bosworth > Application Development and Integration > Communication and Information Services > The University of Newcastle, Australia > Phone: 02 4921 6574 > Fax: 02 4921 7087 > Mobile: 0438 492518 > Email: [EMAIL PROTECTED] > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > >>> [EMAIL PROTECTED] 1/06/2004 12:13:20 pm >>> > Just to clarify - > > The CFC is not changing specific application scope data - i.e. there is not a > > > application.myCFC = createObject(...); > application.myStruct = new Struct(); > > and the myCFC is tinkering with the myStruct scope. > > The myCFC has private members within itself that it manipulated (which is > fair enough). > > I'm saying that if there is the possibility of thread safety, it should be > locked. > > HOWEVER, I'm advocating the use of a NAME lock, rather than a SCOPE lock - > i.e. > > <cflock name="thisisMyLockName" ....> > > NOT > > <cflock scope="APPLICATION" ...> > > (Just to reiterate that point) > > The latter directly ties the CFC to the application scope, however the former > means the CFC is thread safe > no matter WHERE you use it. > > > A component should not know how it is actaully implemented outside of > itself, > > it should be scope independent. > > By your own words - if there are going to be an issue with thread safety, > however the CFC should have > DEFINATLEY locking in it. > > That make more sense? > > Mark > ------------------------------------------------------------------ > [EMAIL PROTECTED] > ICQ: 3094740 > Safe From Bees > [ www.safefrombees.com ] > > > Quoting Stephen Bosworth <[EMAIL PROTECTED]>: > > > Mark, > > > > > I think locking SHOULD be encapsulated in the object. The CFC should be > a > > black box as such.. a > > developer shouldn't have to KNOW to lock it. > > > > A component should not know how it is actaully implemented outside of > itself, > > it should be scope independent. > > > > Everywhere you call a method on your object (component) that has the > > potential to manipulate its private data in application scope, the method > > calls should be locked with a named lock. > > > > The best way would be to not include your locking inside of your > component. > > > > Even if you are using wrapper components to instansiate a number of > objects > > in application scope, the lock should be placed around the instansiation > > call, not inside the component. > > > > I'm not saying what you are suggesting won't work, its just not the best > > approach IMHO. > > > > cheers > > > > -- > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Stephen Bosworth > > Application Development and Integration > > Communication and Information Services > > The University of Newcastle, Australia > > Phone: 02 4921 6574 > > Fax: 02 4921 7087 > > Mobile: 0438 492518 > > Email: [EMAIL PROTECTED] > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > >>> [EMAIL PROTECTED] 1/06/2004 11:32:40 am >>> > > Before i wrote the post - I actually decided to use NAME locking to make > sure > > that my data wasn't going to > > go all wonky on me due to multithreaded conditions. > > > > I think locking SHOULD be encapsulated in the object. The CFC should be a > > black box as such.. a > > developer shouldn't have to KNOW to lock it. > > (Unless stated in documentation) > > > > I mean - what happens if a CFC calls it's own functions? (which this one > does > > - it handles all my CFC > > persistance) - having external locking doesn't work there does it? > > > > It's an interesting question however, isn't it ;o) > > > > Mark > > ------------------------------------------------------------------ > > [EMAIL PROTECTED] > > ICQ: 3094740 > > Safe From Bees > > [ www.safefrombees.com ] > > > > > > Quoting Theo Galanakis <[EMAIL PROTECTED]>: > > > > > I understand your dilemma.. It such a scenario I would not explicitly > have > > > application locking within the object, however I would have the lock > > > encapsulated around the code instantiating or calling functions within > the > > > application resident cfc. > > > > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On Behalf Of Mark M > > > Sent: Tuesday, 1 June 2004 11:09 AM > > > To: CFAussie Mailing List > > > Subject: [cfaussie] Odd Scope / Locking Question > > > > > > I just had a weird thought. > > > > > > If I have a CFC that I persist in the application scope. > > > > > > Inside that CFC I have a struct. > > > > > > When I go to edit that struct, does that require a APPLICATION scope > lock? > > > (assuming there could be cause for multi-thread issues) > > > > > > Mark > > > ------------------------------------------------------------------ > > > [EMAIL PROTECTED] > > > ICQ: 3094740 > > > Safe From Bees > > > [ www.safefrombees.com ] > > > > > > > --- > > You are currently subscribed to cfaussie as: > > [EMAIL PROTECTED] > > To unsubscribe send a blank email to > [EMAIL PROTECTED] > > > > > > MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia > > http://www.mxdu.com/ + 24-25 February, 2004 > > > > > > --- > > You are currently subscribed to cfaussie as: [EMAIL PROTECTED] > > To unsubscribe send a blank email to > [EMAIL PROTECTED] > > > > MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia > > http://www.mxdu.com/ + 24-25 February, 2004 > > > > > > > > --- > You are currently subscribed to cfaussie as: > [EMAIL PROTECTED] > To unsubscribe send a blank email to [EMAIL PROTECTED] > > > MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia > http://www.mxdu.com/ + 24-25 February, 2004 > > --- > You are currently subscribed to cfaussie as: [EMAIL PROTECTED] > To unsubscribe send a blank email to [EMAIL PROTECTED] > > MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia > http://www.mxdu.com/ + 24-25 February, 2004 > > > --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia http://www.mxdu.com/ + 24-25 February, 2004 This message may contain privileged or confidential information and is intended only for the individual named. If you are not the named addressee you should not disclose, disseminate, distribute or copy this e-mail. If you have received this e-mail by mistake please notify the sender immediately by e-mail and delete this e-mail from your system. You should rely on your own virus checking programmes and procedures for checking any attachments. Please advise us if you wish your name and e-mail address to be removed from our database. --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia http://www.mxdu.com/ + 24-25 February, 2004
