G'day mate: The chief reason you needed to do this in CF5 was because CF5 was crap. Well its memory management was crap anyhow... And it was entirely possible for CF to try to allocate the same memory to more than one variable at a time, which is... "not optimal". Especially if the variables don't directly map to the same sequence of memory. Eek.
This has been sorted in CFMX because it's built atop Java, and Java seems to have at least slightly more of a clue how to manage memory. The other issue with shared scope variables is the concept of "race conditions" (Jim Davis has described it well here http://www.depressedpress.com/DepressedPress/Content/ColdFusion/Guides/L ocking/8-Advanced-RaceCondtions.cfm). This sort of situation still needs to be addressed, and simply copying everything into another scope in Application.cfm and then back again in OnRequestEnd.cfm in no way protects against this. You could copy one session variable into request, and then perform two different operations on it in two different requests. Which of the results do you want back in session? It'll just be the last to complete. Or a third request might commence after the first one finishes, but before the second one finishes, and that third request would be using the result of the first request, when it might more properly be needing to use the result of the second request. These analogies are easier to see if you think "application scope" rather than "session scope", but the same issues are present when dealing with session variables, just less likely to occur. Sadly "less likely to happen" is still not "won't happen", so could need some treatment. The bottom line it was *critical* to lock all session variable usage in CF5, for the memory allocation issue; that issue is gone. But there's still the "less critical" issue of race conditions. Adam Cameron Senior Application Developer Straker Interactive Ph: +64 9 3605034 Fx: +64 9 3605870 Email: [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Clifton Steve Sent: Wednesday, 2 June 2004 11:18 a.m. 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
