Mark, I was reading what you sent, in fact, I was discussing it here with a couple of fellow workers.
We are obviously at a lost as to what you are trying to explain/discuss here. Can you provide a code example of people like me you cannot understand what you are trying to acheive can gain an idea as to what you are trying to do exactly. 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 2:31:36 pm >>> Not my question - But that scenario will create errors - I know, I've done it ;o) Hence the discussion of the use of locking internal to a CFC. Maybe I'm not being clear. Never the less, it was more of a discussion than a question as such. About what is considered Scoped as application, and what isn't. It's not really important anyway. Mark ------------------------------------------------------------------ [EMAIL PROTECTED] ICQ: 3094740 Safe From Bees [ www.safefrombees.com ] Quoting Theo Galanakis <[EMAIL PROTECTED]>: > 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 > > > --- 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
