This content has been marked as final. Show 7 replies
> I am building a multiuser site with session vars.
Which CF version?
> I understand the need for
> exclusive locking when writing session vars,
One hasn't had to - intrinsically - do this since CF5.
Read the docs regarding when to lock shared-scope data:
> Also, Is this
> bad? <cflock scope='session' timeout='30' type='exclusive'> <cfset mySess =
> session /> </cflock>
This will achieve little, as it will simply create a reference to the
session scaope, rather than a copy. All you're doing is referring to the
same shared-scope data (with the same potential issues) via a different
On the whole, locking shared-scope data is far less of a concern since CF5
than it used to be.
If you want to do some reading, read the doc I pointed you to, and Google
CFLOCK. This conversation has been well documented several times in the
past (and at least ocne on these forums within the last month or so).
This cannot be true. I am using CF8. Without an exclusive lock on both reading and writing my application's session variables I have witnessed my users getting their sessions mixed up.
Example: My users (average of 150 concurrent) all get content generated from a single SQL view, and we pass in their userId using cfqueryparam. If I do not wrap that query in an exclusive session lock, users randomly see results that are not meant for their eyes.
That sounds like a problem with the variable scoping.
> This cannot be true. I am using CF8. Without an exclusive lock on both
> reading and writing my application's session variables I have witnessed my
Session variables aren't shared *between users*. They're specific to a
user. The only time you're going to be getting contension with a session
variable is when a single user has two browser windows open hitting the
same site. If you've got some weird session bleeding between different
users, then <locking the session scope isn't going to help.
You're problem is something else, and your locking strategy is at best
dealing with it coincidentally. Which should be a bit of a concern...
Groan. I give up.
If I do not wrap that query in an exclusive session lock, users randomly see results that are not meant for their eyes.
The answer might simply be to rename a variable into session.someResult. In fact, you could even do this: