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
