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. > > 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. > > Search the archives here and you'll find a lot -- and I mean a LOT -- > > of information on this. > > And much of it is incomplete, misleading, or plain damned wrong. I trust > what Ray has written, though. Agreed :-) -- --mattRobertson-- Janitor, MSB Web Systems mysecretbase.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:206014 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
