> On 5/8/05, Adam Churvis <[EMAIL PROTECTED]> wrote: > > > Raymond Camden's "Tips for CFMX-ifying your ColdFusion 5 > > > Applications" > > (http://www.macromedia.com/devnet/mx/coldfusion/articles/updating_legacy.htm > > l) > > However a cflock will not help you in such a case. > > > You'll get one set of writes from one window, and a corrupting set > > > from the second *perhaps*, but the solution to that won't come from > > > cflock. This is something you'll have to assess when you look at your > > > app and what it does. > > > > That's simply wrong, Matt: a CFLOCK *will* synchronize the two windows' code > > if a race condition is possible. That's exactly what it's for. > > For a cflock to be a mitigating factor -- within the *session* scope > -- it would have to be mediating between to *simultaneous* user > requests. Thats not realistic *single* user behavior when moving > between two windows. I'm not saying that two open windows can't cause > problems that will need solutions. Just that CFLOCK is unlikely to be > of any use in that solution. Can you give me an example where the > two-window scenario is otherwise for the session of a single user? I > suppose I can think of some -- perhaps you have some sort of variable > whose value must progress in a certain order so that other things > reading it can act upon that expected order -- but that seems an > awfully unusual scenario. > > Make no mistake... on CF5 on down I follow "lock it or lose it" on > everything in every shared server-memory scope. But I have not to > date seen a MM-based resource that contradicts my earlier statements.
I don't try to second-guess unusual scenarios under which race conditions might not need locking; I just lock them according to the rules, and if that unusual scenario exists then fine. We have examples of this that we show in our MX Master Class so people can see the results live. > > > Its woth mentioning that, given the race-conditions-only proviso now > > > in effect for CFLOCK, and the fact that there is no longer any issue > > > with thread safety or server stability, you can consider whether or > > > not you want to ignore *benign* race conditions. > > > You would still CFLOCK this code, but if it is indeed sacrificial code then > > you would specify a relatively low timeout value and also specify > > throwOnTimeout="No" so the code would be bypassed if no lock could be > > acquired in time. > > Now its my turn to say 'thats just plain wrong'. Or perhaps instead > "tell my why there is any reason whatsoever that code which creates a > benign race condition should be locked." Looking at the MM CFMX > Coding Guidelines: > > http://livedocs.macromedia.com/wtg/public/coding_standards/structure.html > > "...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)." > > In the case I was positing, a race condition is unimportant and cannot > affect the outcome. These are not Macromedia's coding guidelines; these are Sean Corfield's coding guidelines, and his statement is wrong. The only thing that synchronizes reads and writes between separate blocks of code is CFLOCK using either the same scope or the same lock name. Using Sean's approach, one block of code could read a value that has not yet been properly set by another block of code. Respectfully, Adam Phillip Churvis Member of Team Macromedia http://www.ProductivityEnhancement.com Download Plum and other cool development tools, and get advanced intensive Master-level training: * C# & ASP.NET for ColdFusion Developers * ColdFusion MX Master Class * Advanced Development with CFMX and SQL Server 2000 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:206024 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
