Nice post. I hadn't given much thought to the implications of a scoped lock preventing access to the entire scope--a very good argument in favor of implementing automatic internal locking, which would only need to lock the specific item being accessed.
Gosh folks, this should be simple stuff for the Macromedia engineers to implement. Accessing a variable in an interpreted language is typically a two step procedure. You look up the name and you get the value. For the duration of the name lookup, you want lock out other processes trying to add or delete variable names. For the duration of the value access, you want to lock out other processes trying to alter the variable value or reorganize the variable heap. There are easy ways to do this which add negligible processing load. Surfacing all of this stuff to the ColdFusion application level is totally unnecessary. In a properly implemented system, using CFLOCK for variable access would be totally unnecessary and provide no benefit. [EMAIL PROTECTED] ----- Original Message ----- From: "Benjamin S. Rogers" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Monday, March 18, 2002 4:31 PM Subject: RE: UDF question > > The question is - do you want CF to automatically handle everything > > for you at the sacrifice of speed? > > Raymond, > > My first question to you is is there ever a reason not to lock access to > Session or Application scoped variables? Personally I can't think of > one, much less one in which the "sacrifice of speed" would come into > play. > > My second question is isn't it true that, assuming all other things > being equal, any algorithm or function coded in binary, compiled > language is going to perform better than one written in a markup > language and executed in JIT or even an interpreted language executed in > a virtual machine? > > Now, assuming the answer to both of these questions is yes, I can only > believe that, in addition to being more stable in environments where > developers don't lock religiously, ColdFusion would actually perform > faster in any environment where developers properly lock all access to > shared scope variables. > > > It would be very difficult to make a system smart enough to know > > "Hey, I could use one lock around this particular block of code." > > Therefore, we would be stuck with the slower alternative. > > What you neglect to mention is that when you lock access to a session > variable, you lock access to all session variables, causing other, > potential more common and severe performance problems, especially in > regards to the "Application" scope. > > In the DBMS realm, these are called hotspots, and though you generally > don't see a performance difference on most systems, a database that > implements such a locking scheme usually fails under a heavy load. > > > Personally, I'd rather just do the work. It can't be that hard to > > cflock, or duplicate to the request scope. > > Did anyone say it was hard? It isn't hard to write your own Java > servlets or roll your own HTTP server in C++. However, the entire reason > for ColdFusion existence, its point of being and single greatest > justification for the cost is that it saves development time. > > Coding three lines of code to every one reference to a shared scope, > inventing workarounds (i.e. synchronizing all the data to the Request > scope or storing serialized session data in client variables) is not my > idea of RAD. In fact, I would say it is the exact opposite. > > God, what would writing SQL be like if I had to manually lock access to > each record before issuing a query? Better yet, people snubbed their > nose at MySQL because it didn't have row level locking but that is, in > essence, how ColdFusion behaves: lock the whole scope instead of the > variable being modified. MySQL has seen the light. Hopefully Macromedia > will one of these days. > > Benjamin S. Rogers > http://www.c4.net/ > v.508.240.0051 > f.508.240.0057 ______________________________________________________________________ Get the mailserver that powers this list at http://www.coolfusion.com FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
