> > The question is - do you want CF to automatically handle > > everything for you at the sacrifice of speed? > > Raymond,
I'm not Raymond, but I'll attempt a response anyway. > 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. I don't think that's what Ray meant. If I understand correctly, his distinction was that the programmer can place multiple variable accesses in a single scope within a single CFLOCK - and can structure his code accordingly - while the stupid computer can't do that: .. begin automatic lock ... <cfset Session.foo = "bar"> .. end automatic lock ... .. begin automatic lock ... <cfset Session.foo2 = "baz"> .. end automatic lock ... vs <cflock scope="session" ...> <cfset Session.foo = "bar"> <cfset Session.foo2 = "baz"> </cflock> > 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? Perhaps so, but "ceteris paribus" doesn't apply here - all other things aren't equal, as previously noted. > > 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. There's a potential problem here, though - the Session and Application scopes are themselves variables. Perhaps this requires that they be locked in their entirety. I don't know enough about the internals of the CF server to be sure, but it sounds possible. > 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. It's my understanding that typically when you're talking about hotspots from a RDBMS perspective, you're referring to a specific issue of locking in conjunction with physical storage - for example, if you place a clustered index on an identity column, concurrent writes to that table will take place within the same physical storage unit (leaf, page, etc) which may be locked. If your database supports locking of individual rows, that should address the issue of hotspots. The potential cost of row-level locking, though, is that the database has to manage more individual locks, which imposes some performance overhead. Now, if we carry that analogy to CF, CF apparently doesn't have "row-level locking" - the ability to isolate a single variable within a memory scope, and lock only that variable. Instead, we have to lock the entire 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. There are always going to be limitations in how easy you can make something. If you made programming easy enough, you wouldn't need programmers, right? (That's the theory behind COBOL, if I recall correctly.) As limitations go, this one seems pretty minor, and is easier than writing Java servlets, or your own HTTP server, or even writing ASP.NET, I think. To put this in a larger context, here's a quote from Drew Falkman on the JRun-talk list, about handling concurrency with session objects in the J2EE server platform: "Well, I couldn't help myself. This is a pretty big issue and I had to know the answer - it is not in the Servlet 2.3 specification. An excerpt from the Session section: 'J2EE.7.7.1 Threading Issues Multiple servlets executing request threads may have active access to a single session object at the same time. The Developer has the responsibility for synchronizing access to session resources as appropriate.' .. Servlet 2.2 is the same: '7.7.1 Threading Issues Multiple servlets executing request threads may have active access to a single session object at the same time. The Developer has the responsibility to synchronize access to resources stored in the session as appropriate.' So there you are - it is up to us... Macromedia is obliged NOT to provide thread safety in order to be compatible with the J2EE spec." Now, it's my understanding that the latest version of JRun does actually synchronize these automatically, so perhaps that'll be done in Neo as well. But it's worth noting that, in any programming environment, there will always be issues important enough to leave within the programmers' control, rather than providing abstractions which don't let programmers do the right thing. Traditionally, I think CF has erred in favor of these abstractions more than once - CFHTTP being a prime example (you can't use it to build many standard HTTP requests). Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ______________________________________________________________________ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists