Matthew, I love that shotgun analogy! Let me take a stab at this issue.
Since session variables are, by their very nature, session-specific, under
normal circumstances there will never be any contention between sessions for
the same variable, either reading or writing. Not "never," just "almost
never." One example would be when an anxious user starts stabbing at a
SUBMIT key (the timing gets a little close in this case), or (better case)
an HREF link to a page that starts something up in another window and that
same anxious user.
Here's how it's been explained to me in the past:
But that's not the reason for the locking. I can have an app where I know
for 100% certain that there can never be two sessions at the same time, and
I still need to lock the session vars. The reason is that I'm not only
alerting the other CF application pages to stay away (Matthew's Do Not
Disturb sign), I'm also telling the CF server's memory manager to stay away.
Matthew's shotgun isn't always in the hands of the other CF application
level pages - it's also in the hands of the CFSERVER itself, when it
performs memory management for all the session vars of all the users of all
the apps on that particular server. When it needs to start doing memory
management tasks (ie, blasting away with the shotgun) then that room had
better be real empty. You'll probably get lucky most of the time, but sooner
or later it's going to be your session var that CF was moving around to make
room for someone else's "session.structuredarrayfromhell" variable, and
wham! Someone is going to get corrupted. If CFSERVER had to check on each
and every reference to a variable throughout your app, just to see if it was
a session var (which is what it tries to do when you turn on the "automatic"
locking) then the performance would go straight down the tubes. But, since
it is pretty likely that you will be referencing more than one session var
within a close proximity of code, then YOU know better as to where to put
the read or exclusive lock to get the best performance. Remember, there's
overhead with setting up and tearing down the lock itself, as well as the
performance hit on forcing certain parts of the code to become
single-threaded. You cannot do much about the latter, but you can reduce
the overhead for the actual locking/unlocking process by using intelligent
locks, rather than letting CF "automatically" put a lock around each
discrete session variable reference. In fact, I'd be willing to bet that
this would generate two "automatic" locks:
<cfset session.this = session.that>
I don't know how much the CF memory management is changing with the changes
that are going on with the underlying engine. I'd love to see some comments
on this from the Allaire crowd, talking at the system level, instead of just
the application programming level.
-reed
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
