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
