> There was another post about this I could've responded to, but I deleted > it, > hence this new post.
> This article: > http://www.macromedia.com/v1/Handlers/index.cfm?ID=23021&Method=Full > Explains why not locking shared scopes won't crash the server, but could > cause a "race condition" and corrupt data. What I don't get is why OTHER > languages don't need locks around shared scopes, if CFMX is indeed > thread-safe like they are (ASP to name one). Basically this article says > "The good news is your server won't crash -- the bad news is, your data > will be totally useless." To me, that says "You still have to lock > everything you always had to, unless you want corrupt data." I'm > sorry, but it seems like a lot of double-talk to me. Race conditions aren't a CF-specific issue. They're a multi-tasking or multi-threading specific issue. Meaning that -- within a single thread ( given any non-multitasking environment like MS DOS is in essence a single-threaded environment ) you can't have a race condition because there's only one thread and within that thread each action or process must wait its turn. Once you have more than one thread, there is the possibility that the actions or processes being peformed within these threads could overlap and cause problems. Example: You have a sequence of actions which must occur in order to successfully perform a given task. insert into db get inserted record from db Now you have 2 threads doing the same thing. If each thread is able to get in and get out without another thread getting in the middle, you're okay, but without locking the sequence in some way, the potential exists that you could get this result instead: thread a: insert into db thread b: insert into db thread a: get inserted record from db from thread b thread b: get inserted record from db from thread b This is obviously not what you want, but it's also very definitely not a ColdFusion or even an MX issue. The same thing can occur ( afaik ) using ASP or other dynamic content servers, unless they are all single-threading their sessions. In CF 5 there's a checkbox in the administrator to single-thread sessions, which I believe means each given page will finish processing before the next page is allowed to begin. I can't remember off the top of my head if this is still true in MX, though I suspect they didn't remove it. It's not used much because it slows the server down, particularly under heavy load. The example above is handled most often with cftransaction so you can see that the issue of race conditions isn't specifically a cflock thing, or for that matter, ASP is liable to have the same issue. > In the article they give an example of updating a variable called > session.cartTotal. What if I have two pages -- one that just reads this > variable, and the one they show that reads and performs an update of the > variable simultaneously. Isn't it possible that these two disparate pages > would cause a race condition, proving that you still have to lock? Yep. It's nothing new. It's all the same concurrency type stuff that gets talked about in CS courses, dining philosophers and all that. > If I am wrong about this, can anyone explain in English, so my tiny little > brain can comprehend why? How's my english? I can never tell. ;) S. Isaac Dealey Certified Advanced ColdFusion 5 Developer www.turnkey.to 954-776-0046 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com
