> Raymond Camden's "Tips for CFMX-ifying your ColdFusion 5 > Applications" (http://www.macromedia.com/devnet/mx/coldfusion/articles/updating_legacy.htm l) > discusses the need to only lock in case of race conditions. If your > application uses *any* persistent scopes (client vars included) you > have to deal with the concept of a user opening up, for example, a > second window. 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. > 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. For example, if you > have the statement "You are visitor #application.thiscount# today" you > may well ask "who cares if the count is of by a couple?" If the > answer is that it doesn't matter, you can skip locking the write and > reads of this variable. 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. Always practice safe sex with your code. > A more realistic example would be your datasource access info. The > name, username and password is commonly tossed in the application > scope. It rarely changes if ever. Same with stuff like paths. In > turn these are often converted to the request scope so they can be > used without locking in for example a cfquery statement. Here's > another example where you can set the vars once in the application > scope, not bother with a lock and use the application vars directly in > cfquery statements, without locking and dispensing with the conversion > to request vars. This is what some people refer to as "Write-Once Constants" since ColdFusion (unfortunately) has no concept of constants. If a value doesn't change then there is no possibility of a race condition of any kind, so no locking is needed. This is what we do in Plum. > 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. 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:206006 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=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
