-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> So what about Application variables that never change (say a list
> of countries or something)? Do they need to be locked?
They *should* be locked. Realisticly, I've got a million-hit-a-month
site that does:
<Cfquery name="blah"
datasource="#Application.OLEDBDSN#">...</cfquery>
It does that unlocked read at least twice per page request without
any problems that I've noticed. "According to the docs," ALL
accesses should be locked, but if your code can guarantee that it
won't be written to, you'll likely be safe. Note that if you have
451 set for full checking, that query above would fail because it
wasn't locked. You'd need to set it for auto read locking, but at
that point you'd be better off locking it yourself, in terms of
performance.
> Is it the possibility of reading data that is
> changing that is the problem, or is there a
> problem with two sessions reading the same
> variable at the same time.
To the best of my knowledge, it's the former, not the later.
> Why would this bring a server down?
> I don't get it.
Corrupted process memory. Let's look at a techy example:
Say you've got a string:
<cfset Application.AString = RepeatString(" ", 200)>
Let's assume one CF thread has just started to read that string.
<cfset LocalString = Application.AString>
(Let's also assume no locking is in place.)
The read process involves the following:
1) Get the length of the string from the prepended integer.
2) Scan through 200 characters, using pointer indirection.
Now... Say another thread starts writing to that string immediately
after the first thread got its length.
<Cfset Application.AString = "12345">
If this second thread shortens the string to 5 chars and frees the
memory used by the other 195 characters, then there's a good chance
the first process will keep reading for 200 chars. Once it gets past
5 it page faults, and so the tower of Babel begins to fall...
> I thought the problem was simply session 1 reading a
> variable, session 2
> changing the variable, then session 1 doing something based on the
> out-of-date value (e.g. writing to the wrong database record
> or whatever).
Oh! If only it were that simple!!! When two or more threads are
working on the same unlocked memory, the end result is nothing less
than leaving CFAS' process memory corrupted. And so you get all
sorts of odd ball exceptions, warnings, etc. I once had CFAS tell be
there was an error on line 4,987,432 of a 40 line file!
Here's the basic history of automatic locking in CFAS:
In every version before 4.5.1, Allaire claimed they didn't do
automatic locking because it was a performance hit. More likely it
was because they were too lazy.
Those prior versions WERE fairly forgiving if you didn't lock things
yourself, and they never really documented that it was important to
do locking. So there's a huge body of CFML written with no locking
whatsoever.
For some unknown reasons, when 4.5.0 came out, it was suddenly very
UNforgiving of unlocked access to shared member. Allaire scrambled
to release 4.5.1 which has some automatic locking features along with
a ton of bug fixes.
At this point, you can certainly use the auto read locking setting of
4.5.1. With that setting, you need to lock any writes to shared
memory, and the server will scold you if you don't. That's probably
the best setting for ISP's as well.
For a little bit more performance, tho, you should consider doing all
of your locks yourself. If that's the case, you DO need to lock both
reads and writes. The reason for that is that if CFAS incounters a
CFLOCK to write to a variable, but there are no CFLOCKs around your
reads, CFAS will grant that CFLOCK to write even tho other threads
could be reading that variable at the time. It has no way of knowing
that the variable in question is being read from unless there are
locks around those reads.
Best regards,
Zac Bedell
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBOYFt3graVoMWBwRBEQII1QCeLsJK36g1sanM1gDZgM6Y/sl6segAnjbq
eRjrBRg/C5fyDTfyQzuWJPyb
=wAUH
-----END PGP SIGNATURE-----
------------------------------------------------------------------------------
Archives: http://www.mail-archive.com/[email protected]/
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
