This may sound stupid but did I read somewhere that it *really* wasn't necessary to lock writes to shared scope variables in MX? That seems impossible to me but...
You only need to lock to prevent race conditions.
Also, assuming you do have to lock writes, is it preferable to use the name
attribute rather than scope?
This is from our Coding Guidelines (3.0):
"Locking & Shared Scopes
When accessing and / or updating data in shared scopes, always consider the possibility of race conditions (i.e., where two concurrent requests could access and / or update the same data). If a race condition is possible and might affect the behavior of your code, you need to use cflock to control execution of the code around the shared resource.
If the shared resource is in server or application scope, you should use named locks to control access - and choose a name that uniquely identifies the resource being locked, e.g., use server_varname when locking an update to server.varname.
If the shared resource is in session scope, you should generally use a scoped lock on session itself.
In both cases, remember that you are only trying to prevent race conditions affecting your code: most read operations do not need to be locked; most write operations should be locked (unless the race condition is either unimportant or cannot affect the outcome)."
<!---lock one session variable----> <cflock name="session.UserID" type="exclusive" timeout="10"> <cfset session.UserID = someValue /> </cflock>
<!---on another page----> <cflock name="session.Cart" type="exclusive" timeout"10"> <cfset session.Cart = aStructure /> </cflock>
Would these locks have no bearing on each other?
Correct, they are independent locks although with session scope, you might as well lock on session scope since you'll only block one user...
Sean A Corfield -- http://www.corfield.org/blog/
"If you're not annoying somebody, you're not really alive." -- Margaret Atwood
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
