-----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?....
> >*snip* < <
>
>
> Thanks for the extensive explanation. A couple finer points still
> aren't quite clear to me. When you say "will lock all of your
> session vars", from the rest of your explanation, I gather you
> don't
> mean all of
> the session variables from all sessions in all applications running
> on the server, just all of the variables from one particular
> user's session
> within that particular application.
The lock only applies to the current session. Under 4.5.1, you do
that with scope="session"; under 4.0.1, with
name="#Session.SessionID#". You can still have a million sessions
executing at the same time, but only one exclusive lock for each of
those sessions will be executing.
> When you talk about thousands of users hammering an application, I
> can certainly envision this. But it would seem to me that session
> (and client) variables are the least endangered shared data, since
> each user
> has his/her own set. It's of course possible for a user to have
> multiple windows open, or you might have an application using
> framesets
> that reference the same session variables, but the chances for
> contention would still seem to be pretty low. I'm not arguing
> against locking, just trying to understand "who" is contending for
> these shared
> variables.
You've got it exactly there. Application & server vars carry the
worst risk of multiple accesses. Multiple browsers, frame sets, and
anywhere that a single page might spawn more than one CF request (via
JScript, or using img src="*.cfm") are all chances for contention on
session vars. Multiple access to session vars don't happen all
*that* often, but you still need to lock for just such an occasion.
> The CF docs state: "For session variables, you must assign the
> session ID for the lock name." Is that "must" as in "required by
> the server", or "must" as in "this is what we recommend".
"Must" as in that's what the guy writing the docs was told & didn't
know any better... You can also use the CFID/CFTOKEN as a locking
name. Basically anything that's guranteed to be unique across
sessions is safe. SessionID just happens to be a really convenient
choice. And of course that's all moot under 4.5.1 with scoped
locking.
> Could a
> developer gain in
> locking granularity by extending the lock name as in
> name="#session.sessionid#_variablename"?
Hmmm.... Now that's one I don't know. I would *suspect* that the
entire session structure for a particular session must be locked for
safety, so I don't think that granular locking would be safe. I
don't have any hard evidence to support that, but given the way the
C++ works and how Allaire would likely have coded things, I believe
that's correct. No way to tell for sure without source...
Hope that's helpful.
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/AwUBOa6+VQraVoMWBwRBEQJqLQCgils7Udk3Bxkf/CYr3kgbyOOgFEkAn2Y8
XmMgavfybj81TjMPrZOt9yk3
=ZdQi
-----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.
