Cflock session - named or not?

Question

I juts went through a bunch of apps and cflocked the heck out
of lots of session variables being set. This greatly improved my
server problems. However, I locked these all with a Name and not
the Scope
Now my server is getting quirky again and I want to see if
this is my issue.
I ahve read contradictory thinsg online about whether a
session variable should be set as scope="session" or given a unique
name.
So which is best?

Answer 1

> Well... *precisely*. You're demonstrating *my* point, not
yours.
> You cited this example:
> <cflock scope="SESSION" timeout="3"
type="READONLY">
> <cfset session.clientBalance = session.clientBalance
- 99.50>
> </cflock>
No need to waste time there. I corrected it two days ago.
> There is no need to lock this. CF code is automatically
locked @ statement
> level, so that ONE line of code cannot be
*simultaneously* accessed by two
> threads.
> What Might happen in CF5 is that two threads could hit
that line of code at
> exactly the same time, and increment the SAME
session.clientBalance value
> twice (meaning one increment is lost). That's bad. And
accordingly you
> needed to lock the code so each thread would hit the
code in turn.
> However this cannot happen in CFMX. Java forces one of
the threads to wait
> until the other finishes, and THEN the second thread
runs that statement
> (so two increments, one for each thread: correct).
> Basically, the session scope is "synchronised" at a Java
level: each
> operation on the session scope is queued, so it's
impossible for two
> operations to take place at once. Hence not needing to
lock individual
> CF statements.
I suppose what you mean is that, since version MX, Coldfusion
is thread-safe. Two threads will therefore not modify a variable at
the same time. As I said before, that is not an exact science.
Thread-safety is complicated by technical matters as atomicity and
reentrancy. Note in particular that <cfset session.clientBalance
= session.clientBalance - 99.50> is a recursive statement.
> The crux of this is that telling someone they need to lock
a single <cfset>
> because it deals with the session scope is outright
wrong, post-CF5.
This
MX7
livedocs on locking explains how and why to lock a single
cfset.