-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> Thank you Zac, that made a whole lot of sense.
You're more than welcome! I just with Allaire would make an official
statement to that effect. All of what I said was of course only my
best guesses from experience. You might be able to get away with
less, but any time I've tried, I've been sorry...
> So henceforth I'll lock everything except data
> that never changes like Application.DSN, i.e.
> data that only gets set if Not IsDefined... If
> it's not defined, no other process can be accessing it.
That sounds reasonably safe. Just make sure you lock it when you do
actually write to it. There's still a *chance* of problem here,
since the exclusive lock when you write to the variable can't
possibly know about the other unlocked reads going on. But since
you're probably taking about variables written to once the first time
application.cfm is called, you'll definately be okay -- that's what I
do on the million a month site without problem.
> One final thing? Should locks be wrapped around
> "large" chunks of code that mention say a session
> variable/s several times? How large a chunk would
> you consider reasonable to lock? Or is it better
> to have a zillion locks each wrapped around one
> reference to a variable?
Your best bet is to copy the session or application variables to
local variables and then use those in your code. Vis:
<cflock scope="Session" type="readonly" timeout="10">
<Cfset LocalVar = Application.Var>
</cflock>
<cfoutput>
blah blah #localVar##localVar##localVar##localVar#
<!--- (Lots of accesses to LocalVar) --->
</cfoutput>
If you need to make changes to the variable in the block of code,
then you'll need to evaluate things a little before you decide
whether to use the above approach or to lock the whole block. If
you're doing time consuming things like queries or sending email in
that block, then you may well have a performance bottleneck as only
one client can hit that code at the same time.
If the changes you made to the variable are not likely to be effected
by race conditions (tho they probably ARE...), you could use the
above, then at the end of the code do:
<cflock scope="Session" type="exclusive" timeout="10">
<!--- Write LocalVar back to shared memory --->
<Cfset Application.Var = LocalVar>
</cflock>
But that's likely to cause problems as two pages make changes to the
same data and then both write their changes back to the shared
variable. That one's kind of a judgement call based on what your
code is doing.
As a general rule, you'll want to keep locked sections of code as
small as possible. Even if you have a dozen processor machine
running your program, when you've got more than one client accessing
a page w/ an exclusive lock, the entire server has to WAIT until that
lock is free for other request to complete. Basically, you'd have
one processor working as hard as it could to complete the request,
and 11 processors waiting. Not fun...
> Interesting to note that in the CF docs (the
> HTML ones, anyway) they've replaced <cflock
> name...> with <cflock scope...> in the examples
> but they haven't really changed the text to
> match. Perhaps they used their automatic wizard.
*shudders* Don't get me started on Allaire's documentation.....
We're considering starting our own internal errata list for our
developers....
Best regards,
Zac Bedell
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBOYGDlQraVoMWBwRBEQIrXgCgx2IuGt/FmqR14GBMF4h3zSS/gxMAoM21
AAOcorBYcG2kSEvpQmNzhbER
=4HQU
-----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.
