[thesite] CF error on home page

jeff jeff at members.evolt.org
Thu Dec 21 07:17:16 CST 2000


: From: Oliver Lineham
: suit yourself.

not just suiting myself - speaking from experience.

: personally, if other people who i have no control
: over or contact with are using the same server
: as i am, i am happy to take a very small performance
: hit to ensure their sloppy coding doesn't bring
: down my whole site.

even to the point where full lock checking could be that extra burden the
server can't handle without causing larger performance issues?  why not
consider that it's off by default in an install for a reason?

: and it is a very small performance hit, from my tests.

on the contrary.  there are numerous developers with lots of background in
large-scale application development and testing who disagree with you.  all
of their conclusions indicate that full checking is a large performance hit.
if you think about the additional steps the server has to perform to
accomplish this task you wouldn't be saying that.  further, loading up a
page in your browser and hitting reload a couple of times a second and
watching the parse times is not a true performance measure.  neither is
having 5 or 6 of your friends do the same thing.  you can't accurately
assess a performance gain or a performance loss without the proper software,
experience, and training.

: >there is indeed an option to perform read-only locks.
: ..which i never mentioned or suggested. i've only been
: talking about full checking, not auto read locking.

actually you just mentioned auto lock checking in general in your initial
post.  you didn't mention whether you meant full or read-only.

: really?  if you put the locks in as you go, it's not
: cumbersome at all, in my experience.  hardly
: "development overhead" worth worrying about,
: for the gain in reliability you potentially gain.

try telling that to an inexperienced developer who just wants to put
together something simple for himself or a client.  adding the complexity of
knowing how and when to lock variables could make the task impossible.  the
fact that you understand them is not an indicator of how easy they are to
work with.  the fact of the matter is that there are numerous developers
that are unsure.  if you don't believe me go read some of the messages on
cf-talk.  there's a cflock thread about once every two weeks.

besides, weren't you the one who didn't understand the difference between
variables with dots and variables that are initialized as structures?  you
even complained about how the language was ugly and primitive compared to
the "big" languages yet you forgot one of the most basic things you learn in
those "big" languages which is "typing" your variables when you define them.

: not locking shared data accesses in a web application is
: like not deleting pointed-to objects in a C++ application. the
: application still "works" and the programmer hasn't had to
: think about pesky things like memory leaks.  the product is
: just of lower quality.

lower quality is a relative term.  if the product has relatively low use
there simply isn't a need for using locks and the small loss of performance
associated.  if i'm building a set of administrative tools for a client and
those tools are going to get very light traffic (ie very few, if any
simultaneous requests) then what's the point of locking the variables?
there isn't any because you don't really start to see the advantage of
locking until you experience traffic loads high enough to force requests
that cause simultaneous reads and/or writes.

: you said "getting definitive information about how
: to correctly lock reads and writes of session and
: application scoped variables is difficult."
: what is unclear about the language reference's
: cflock documentation?

why don't you ask that same question to the people that are asking about
cflock and how/when to use it about once every two weeks on cf-talk?
obviously there's something missing or unclear.



mailto:jeff at members.evolt.org

More information about the thesite mailing list