despite the fact that you're not raymond, i'll respond to him via your response for
him (how's it feel to be a surrogate ray? :))
"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>"
of course, that's the point of a well written compiler/interpreter. it can figure out
that it's SUPPOSED to do the second. that's what makes it well written.
christopher olive
cto, vp of web development, vp it security
atnet solutions, inc.
410.931.4092
http://www.atnetsolutions.com
-----Original Message-----
From: Dave Watts [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 19, 2002 12:58 PM
To: CF-Talk
Subject: RE: locking (was: UDF question)
> > 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
______________________________________________________________________
Your ad could be here. Monies from ads go to support these lists and provide more
resources for the community. http://www.fusionauthority.com/ads.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
