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
