> 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.
All of them should be locked, but each session should have its own unique
lock, which is what the SCOPE attribute makes easy. When you lock session
variables, you're only locking the variables for that specific user.
> 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.
This does seem like the "common sense" conclusion. However, there are two
problems here.
One is that browsers use multiple threads to make HTTP requests, and
apparently it's possible for the browser to "accidentally" request something
twice; if for example thread 1 requests a page, but doesn't get any
connection, thread 2 might try to do the same thing. If your server is under
heavy load, you can see how it's possible for thread 1 not to get serviced
in time.
Another problem is that it apparently doesn't take much memory corruption to
make CF Server unhappy. You're going to have more memory allocated to
Session variables than Application variables, so even if it's less likely
that a specific session will suffer concurrent requests, the fact that there
are so many sessions running makes it more likely that one of them will.
In any case, under heavy load, you will have serious problems unless you
lock memory variables.
> 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".
This is kind of unfortunate; this is what Allaire recommended with CF 4.0.x,
but with 4.5.x you'd want to use the SCOPE attribute instead of the NAME
attribute for locking memory variables.
> Could a developer gain in locking granularity by extending the
> lock name as in name="#session.sessionid#_variablename"?
No, because what you're trying to lock is the session itself; not
necessarily the specific variable within the session. Remember that the
session is a Structure, and you're using that structure whenever you create
or modify or read a session variable.
Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
voice: (202) 797-5496
fax: (202) 797-5444
------------------------------------------------------------------------------
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
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.
