That is correct. Duplicating of shared scopes into the request scope is no longer necessary for locking reasons. It is still a valid thing to do though, so if you have legacy code it is probably safest to stick with it in those apps. For new apps it wouldn't achieve much other than to hurt performance.
You can modify variables in shared scopes as long as you aren't doing something like this: <cfset Application.hitcount = application.hitcount + 1> i.e. Where you are using the value on both sides of an assignment. That is known as a race condition and should be locked because there is a possibility that 2 threads could be executing the same code concurrently, or near enough concurrently for the values to get mixed up. Spike -------------------------------------------- Stephen Milligan Code poet for hire http://www.spike.org.uk Do you cfeclipse? http://cfeclipse.tigris.org >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of >Clifton Steve >Sent: Tuesday, June 01, 2004 3:18 PM >To: CFAussie Mailing List >Subject: [cfaussie] RE: Form scope weirdness or ........ > >Adam, > >So you're saying that the copying of session scope to request >scope and back again is no longer necessary in CFMX? Or at >least, the locking of these processes is no longer required? >Does this mean I can happily (and >safely) use, add or modify any session vars on a template >without locking? > >Steve > > >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of >Adam Cameron >Sent: Wednesday, 2 June 2004 8:51 AM >To: CFAussie Mailing List >Subject: [cfaussie] RE: Form scope weirdness or ........ > > >>this is a CF5 best practice that i have maintained in CFMX. > >But the reason that existed in CF5 to do this is no longer >present in CFMX. There's no need to lock shared-scoped >variables in CFMX for the "memory corruption" problem that CF5 >has, and this practice in no way protects against race >conditions (in fact it makes it *worse* in some >cases) which is the other reason to lock shared-scope variables. > >So tread with caution there, I'd say..? > > >Adam Cameron >Senior Application Developer >Straker Interactive > >Ph: +64 9 3605034 >Fx: +64 9 3605870 >Email: [EMAIL PROTECTED] > > >--- >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
