-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Okay...
Last time now...
This is your server [holds up egg].
This is your server with out locking [*sizzle*].
Any questions?....
But seriously... Please allow me to clear up a couple of
misconceptions in this post.
>> Does a CFLOCK with name="#session.sesionid#" only lock the
>> variables in
>> memory for that particular session, or does it lock all session
>> variables for the application?
>-- Quoting someone else's thread too:
>It locks all of the CFLOCK blocks where name="#session.sessionid#".
>Practically speaking, it locks all of the session variables for that
>particular session.
That's not 100% true. In practice, IF YOU DO ALL OF YOUR LOCKING
PROPERLY, then a CFLOCK with name="#Session.SessionID#" will lock all
of your session vars. Doing your locking properly means you need
CFLOCKS around every single access to a session var, whether it's for
reading or writing. In actuality, all CFLOCK does is prevent other
sections of code from entering a block with the same name as another
currently executing lock. (See below for more clarity.)
>> What's the point of using a read-only lock to improve performance
>> of updates if you chance the possibility of corrupting the data?
Read-only locks don't improve performance over not locking. They
gain over an exclusive lock, provided the section locked is indeed
reading only.
>> Do you gain anything in terms of data integrity over using no lock
>> at all?
Absolutey! If you don't read-only lock your reads, then you're not
really locking at all. Here's why:
When the CFML parser encounters a CFLOCK block, it checks the type of
the lock (read-only or exclusive) and the name/scope of the lock.
For a read-only lock, the parser checks to see if there are any
exclusive locks with the same name/scope currently executing. If
there ARE, the CFLOCK will block until the timeout or until the
exclusive lock is freed. If there are no locks or only read-only
locks, then the new read-only lock will be allowed to run without
blocking.
For an exclusive lock, the parser looks for any read-only OR
exclusive locks with the same name/scope. If any locks are found,
then the code will block until the other locks are released or until
it times out.
Now.... Why are read-only locks necessary? Presume you have 10,000
rabid customers knocking at your virtual door... Let's assume that
every page on your site is hit more-or-less evenly, so the sections
that write & the sections that read your session variables are
getting executed all the time.
Given that scenario, assume you exclusively lock all of your writes
to shared variables, but you DON'T read-only lock the reads. Now if
you have 100 people hitting the section of code that writes to the
variable, all of those requests will queue up and execute one at a
time (as they should). BUT if you have 100 other people hitting the
sections of the code that read the variables, those accesses will all
be allowed to happen EVEN THOUGH THAT SAME VARIABLE IS BEING WRITTEN
TO AT THE SAME TIME. So at that point, you have *many* multiple
accessrs to shared memory, and your server's stability will suffer.
Essentially, you're not really locking.
CF uses advisory locking. That means that the CFML parser doesn't
have any clue whether something should or shouldn't be locked (that
changed a *little* in 4.5.1), and it's up to the programmer to
*advise* the parser when to lock. In order for locking to function
properly, you must tell the parser (via CFLOCK) both when you are
reading and writing to a variable. If you only tell the parse about
writes to variables (with exclusive locks), then all of your writes
will single thread as they're supposed to, but any number of reads
could be occurring at the same time as the write.
>> What's a reasonable value for the timeout attribute when working
>> with session variables? I can't think of a reason why 1 second
>> shouldn't be
>> more than enough, but I don't see how setting it higher could hurt
>> either.
I usually use about 5 seconds, but that's really just a number I
pulled out of the blue... You want a number small enough to ensure
that any potential deadlocks don't lock up all of your worker threads
for too long, but you also want to make sure that any temporary
spikes in server load won't make pages time out & send unnecessary
errors to your users. Does anyone with more time to tweak at numbers
like this have any kind of a definitive answer?
So... Does that make sense now. Locking isn't just a good idea....
If you cut corners locking, your server will die a miserable death as
soon as it's placed under any kind of load. So PLEASE, PLEASE,
PLEASE lock all access to session variables, application variables,
server variables, non-threadsafe CFX tags, CFFILE writes, and
anything else that could possibly generate a race condition. You pay
a very small penalty in server performance to manage those locks, but
that's nothing compare to the loss of performance when CFAS crashes
due to invalid memory accesses...
Best regards,
Zac Bedell
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com>
Comment: Please use PGP!!!
iQA/AwUBOa5n2wraVoMWBwRBEQINcwCfZYYIqkOPYxvDRWWlByg8eDq7KnMAn3yM
zqxO5i4+7z6D+TmED9vwp5PH
=cw1L
-----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.
