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
