That gives me some understanding of why I might still need to lock. It seems as though it's mostly a protection against unplanned parallelism (due to unexpected user actions). I will use locking although it seems a little unnecessary as most of my server variables would not cause a problem if read while another intsnace was changing them.
I added the variable "Session.IsLoggedIn" and interrogate it now thru a CFinclude at the beginning of every page. That seems to work.
Thanx a lot.
Main Topics
Browse All Topics
by: raj_Posted on 2002-12-20 at 10:19:03ID: 7614617
answers inline...
1 - Does each user have exactly one set of session variables for the duration of the session (while the browser is open and the session hasn't timed out)? If so, why all this stuff about having to CFlock things? I can't see the reason for it unless they are shared.
ans: (as quoted by Jim davis of http://www.vboston.com/Dep
In general session variables are the least likely to cause locking crashes.
Server (if used) and Application variables are generally used by every or
almost every template - so there's a much greater chance of two threads
competing.
Session variables are linked only a specific token/ID. There are still ways
for two threads to compete for access however:
1) Frames - multiple pages that use the same variables in frames.
2) "refreshing" - a user that refreshes a page multiple times can launch
several threads which may compete.
3) Form Submits - same as above, only a user hits "submit" more than once.
4) Mutliple browser windows - a user can open multiple browser windows.
5) Session sharing - when CFToken and CFID are placed on the URL they can be
inadvertently shared among multiple users creating a situation where more
than one user is accessing the same session data.
There are others, but those are the most common. An application may, for
some reason, not be affected by any (or very few) of those cases.
Also, in CF 4.5-5, you can set "single threaded sessions" in the CF Admin
which would eliminate any potential problem with session variables. Setting
the total available threads to only one or two can also dramtically decrease
the chance for locking problems. In CFMX not locking won't cause a crash at
all - but it might cause weird results.
Although session vars are least likely to cause locking crashes they are
most likely to suffer from race conditions - so you should still be locking
them, even in MX, unless you really know your application.
Q2: ans - as regards this on every page u can have a small cfinclude for a loginCheck.cfm page, which basically checks for the existence of the session.isloggedIn or the variable which u defined, and if not found redirect them back to the login page, with a suitable message, so that the users knows why he was brought back to the re-login page.
good luck
-r