So you wont me to be 100% specfic now, I already stated in my first post what I do to stop the race condition from happening byt locking th setter in the component.
I posted Bens article on CFlock and Race Conditions, as well as a FAQ of the Adobe websote. So if I say that somewhere else changes the variable, you should be smart enough to know that if it is going to occur in a race condition to lock it. So my example was a little more defined that shows a race condtion occuring, the example of the original poster as a setter and getter inside of a component stored inside a session scope, this is well and truely open to a race condition happening so I don't care what anyone says I am under the Best Practice of cflocking that setter in that case, as outline by Adobe and Ben Forta. I should have to say anymore on thje subject. See thats why you are a fool, you are judging one page on one request, you have no idea that it is possible to run into a race condition even if I request one page, and if that page has other components that then require more information either at the same time or happens to run at the same time as your one request then a race conditon is more than likely don't you think. You have to look at the fact that a page request will run in its own thread, and if you have another page request from an Ajax call or FDS or Webservice or whatever, you will instantiate another request or thread and hence be subject to a race condtion scenario that might only happen 1 in a million chances, but there is a chance. So we go back to the origianl User obejct in the session scope, this is open to reads and writes from different threads that might be out of the scope of the developers thinking, and hence because it has a setter and getter stored in a session scope I would take the best practice approach and use a cflock on the memory write. Now thats also one reason I made the coment on cfqueryparam, if I control the information that is going into the cffunction and the conditons no matter where they come from are controled before the query occurs, I do not need to use cfqueryparm. But as I stated earlier, people still use it under the premise that the function will only accept a numeric value, and the argument is type as numeric if anything else is passed in its going to fail anyway, but these people still play it safe and follow best practice and use the cfqueryparam. So me as a developer, would come along and say ok. <cset application.flag = true /> Now as I said and as Sean stated on its own its not a threat to anything, but as I also stated I can't assume on how another programmer might use this, or even how my requirements might change and if you can be absolutly 100% sure that that variable set will never enter a race condition and I mean that another thread can't be running at the same time that could be influenced by this variable then don lock it, but if you can't be 100% sure then lock it and be safe about it. As I said this discussion has raised its head many times on CFCDev, and the answer is always the same when dealling with a scenario with session scope and CFC objects, the best practice would be to lock the writes to the variables. And in this case they are inside a CFC, that is stored inside a session scope, now the developer as I stated earlier in this thread is that he/she can take the intititive to cflock in the setter and cut down on having to rely on the user of the object to do the right thing or, he/she can forget about it and rely on the user of the object to do the right thing. On 4/15/07, Jochem van Dieten <[EMAIL PROTECTED]> wrote: > > Andrew Scott wrote: > > Then your a fool in the making. > > > > Ok, lets say we have 2 threads running. > > > > Thread number one is checking to see if application.flag is true or not, > it > > sees it as true it gets hafl way through its process the second thread > while > > running at the same time has now changed this value halfway through the > cfif > > condition. > > But now you are changing the scenario. The scenario was: > > <cfset application.flag = true /> > > no on its own that can not cause a race condition, but if somewhere else > > there is a read on that variable somewhere then that will cause a race > > condition. > > You are suddenly adding a second thread that changes the value of > application.flag to your scenario. Which is incidentally exactly the > same as the third condition I described. > > Your email wasn't wrong per se, but the scenario you described was > incomplete and hence you were jumping to a conclusion that wasn't > warranted. > > > > That my friend is a typical example of a race condition, dont be fooled > as > > Ben says lock it. > > If I depend on it being the same during the entire request, I will > probably still not lock it, but make a local copy. Only if I need it to > be both the same and recent will I resort to locking. > > Jochem > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| ColdFusion MX7 and Flex 2 Build sales & marketing dashboard RIAâs for your business. Upgrade now http://www.adobe.com/products/coldfusion/flex2?sdid=RVJT Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:275265 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
