Geoff, yes, this is exactly the tone I took w/ our internal people. I
told them to assume that the code wrote perfect name locks.
FYI, as it stands, in my mind, if you work with server.cfa.a and
server.cfa.b, they are the same structure, just different parts of it,
and SCOPE locks are the correct way to do it.
Anyway, we are getting an official answer on this.
=======================================================================
Raymond Camden, Principal Spectra Compliance Engineer for Macromedia
Email : [EMAIL PROTECTED]
Yahoo IM : morpheus
"My ally is the Force, and a powerful ally it is." - Yoda
> -----Original Message-----
> From: Geoff Bowers [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, September 16, 2001 4:48 AM
> To: Spectra-Talk
> Subject: RE: Large mod - locking explanation?
>
>
> Ray,
>
> > On Monday, I'll try to get the official word on,
> specifically, "It is
> > always preferable to use SCOPE= instead of NAME= when using shared
> > access vars."
>
> If you're going to get a definitive answer from engineering
> can you please get a detailed one. A preference statement is
> not enough. As I've said before... we can load test
> applications to the max and leave them there without any sign
> of instability using *correctly* defined named locks on the
> server scope. Being told to SCOPE lock won't really make
> much sense unless it is accompanied by a detailed explanation.
>
> > > A low level, technical answer would be welcomed - not
> some blanket
> > > statement that all writes and reads must be locked as this is
> > > plainly wrong.
> >
> > Um.... no. It's right. At least in my book. Sure, read locking app
> > vars that never change on a site that gets two hits a day
> may not be
> > necessary, but why _not_ code safely? If you don't lock,
> your looking
> > for trouble.
>
> Well we would beg to differ. I've already stated in several
> forums that we have used the APPLICATION scope as a constant
> and quite happily write lock and *NEVER* read lock (except
> during intialisation) the APPLICATION scope. Under whatever
> load this holds up. We have this running in production in
> high traffic and simulated under higher traffic without
> issue. Of course this assumes that appropriate locking is
> used during the intial write of the scope and that you never
> write to the APPLICATION scope again.
>
> Again this just goes to show that the issue of locking has
> *never* been clearly defined. I doubt you'll get a
> satisfactory answer - over the last couple of years we never
> have. The only thing i can suggest is testing and our
> testing indicates the following:
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Get the mailserver that powers this list at http://www.coolfusion.com
------------------------------------------------------------------------------
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/spectra_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
