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:
a) there is no need to READ lock if the the scope can be guaranteed never to
change. We have done this using the APPLICATION scope as a constant.
b) appropriate named locks around structures within a shared scope (eg.
server.stMystruct) are sufficient to prevent memory corruption under any
load.
No doubt all my ramblings just add fuel to the fire :) It's not that we
don't appreciate the modifications and upkeep of the source, we do! Just
would like to know the thinking behind some of these fairly extensive
changes.
Best regards,
-- Geoff
[EMAIL PROTECTED]
Director - Daemon Internet Consultants
Allaire Master Instructor
http://www.daemon.com.au
p. +61 2 9380 4162 % f. +61 2 9380 4204
17 Roslyn Gardens, Elizabeth Bay NSW 2011 Australia
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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.
