*Points below: -- &<------------ 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. -- &<------------
So we agree ;o) Mark ------------------------------------------------------------------ [EMAIL PROTECTED] ICQ: 3094740 Safe From Bees [ www.safefrombees.com ] Quoting Theo Galanakis <[EMAIL PROTECTED]>: > It depends how you intend to use this object. If this object will only be > used in an application scope, then you could use lock within the object. > > I personally believe an object should not be tied down only being able to > run in the application scope. It should be far more independent that that. > > So by not placing application locks within the object and only locking when > calling functions or changing application object variables, should allow > that flexibility. > > Theo > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Mark M > Sent: Tuesday, 1 June 2004 11:33 AM > To: CFAussie Mailing List > Subject: [cfaussie] RE: Odd Scope / Locking Question > > 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 > > 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
