Tom,
I just finished a column on just this subject for the August CFDJ. But to
summarize, locks are necessary if there is EVER a chance that shared
variables are updated. SESSION variables pretty much always need locks.
APPLICATION variables need locks if they are updated, if they are only ever
set once and are never ever written to again then the truth is they do not
need a lock (but ONLY if you can be sure of that). You could use a READONLY
lock to be sure, that does not have any real overhead and you can be safer
that way.
--- Ben
-----Original Message-----
From: Tom Dyson [mailto:[EMAIL PROTECTED]]
Sent: Thursday, July 06, 2000 8:33 AM
To: [EMAIL PROTECTED]
Subject: When should I use CFLOCK?
The Allaire knowledge base article on monitoring memory usage states:
One of the most common causes [of increased memory usage] are improperly
locked access to session, application, and server variables. These variables
are stored in memory and need to be enclosed in a CFLOCK tag with the
appropriate SCOPE attribute specified (i.e. session, application, or server)
when referenced.
while Ben Forta says:
Caution: avoid unnecessary use of <CFLOCK>. Forcing code to single-threaded
use only can seriously impact system performance.
We're building an application which uses session and application variables
on every page (for security and user customisation). Should we use <cflock>
when we read them? Or when we write them? Or both? Does anyone have any
guidelines on <cflock> usage?
Thanks
Tom
----------------------------------------------------------------------------
--
Archives: http://www.mail-archive.com/[email protected]/
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or
send a message to [EMAIL PROTECTED] with 'unsubscribe' in
the body.
------------------------------------------------------------------------------
Archives: http://www.mail-archive.com/[email protected]/
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
