cflock session - named or not?

[Bugsville]

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?

[Newsgroup_User]

All locked code with the same scope OR name share the same cue and
timeout no matter where they are running from. You can use this to your
advantage.

If you want several locks running in different places in the code to
never run at the same time not matter how many threads are running any
of this code, give these locks the same name or scope.

But do too much of this, you will have very long cues of processes
lining up and waiting for their turn to run the code inside the given lock.

Bugsville wrote:
> 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?
>

[pete_freitag]

If your using version 6.0 or greater you don't even need to use cflock in most cases

[Newsgroup_User]

Also if you have given every lock a unique name, but these locks are
runs the same code, you have not locked the code.

Example:

<cflock ... name="foo">
<cfset session.myVar = "george">
</cflock>

And someplace else:

<cflock ... name="bar">
<cfset session.myVar = "fred">
</cflock>

Both of these cfsets can run at the same time, and if this was causing a
problem before the locks, they will still be a problem after the locks.
In this case you would probably want to use the same name or scope.

Now more recent versions of ColdFusion are much better at protection run
conditions in shared scoped variables. So you should not necessarily
need to cope every last instance of them, depending on what you are doing.

Bugsville wrote:
> 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?
>

[BKBK]

There are situations where it is necessary to lock session code. A common example is when a shared variable is updated, as happens in

<cflock scope="SESSION" timeout="3" type="EXCLUSIVE">
<cfset session.clientBalance = session.clientBalance - 99.50>
</cflock>

Therefore, choosing in general not to use locks is not a wise option. It all depends on the code.

[Newsgroup_User]

> There are situations where it is necessary to lock session code. A common
> example is when a shared variable is updated, as happens in
>
> <cflock scope="SESSION" timeout="3" type="READONLY">
> <cfset session.clientBalance = session.clientBalance - 99.50>
> </cflock>
>
> Therefore, choosing in general not to use locks is not a wise option. It all
> depends on the code.

This has not been necessary since CF5. You do NOT have to lock simple
<cfset> expressions like this.

Even in CF5 this example is wrong, because you're setting the variable it
should be an exclusive lock.

The only time you need to lock code these days is to prevent race
conditions.

--
Adam

[BKBK]

A transmission delay of the system, you will have noticed. Apparently, you, newsgroup users, don't receive corrections. The "Readonly" was simply the result of clicking too quick on the automatic tag completor. I had it corrected to "Exclusive" within seconds of posting, one day before already.

> This has not been necessary since CF5. You do NOT have to lock simple
> <cfset> expressions like this.
[<cfset session.clientBalance = session.clientBalance - 99.50>]
> The only time you need to lock code these days is to prevent race
> conditions.

The "simple" <cfset> expression, <cfset session.clientBalance = session.clientBalance - 99.50>, is actually an example of code that can result in a race condition. It therefore requires a lock.

[Newsgroup_User]

> A transmission delay of the system, you will have noticed. Apparently, you,
> newsgroup users, don't receive corrections.

It would seem not. This could be due to articles only going to the NNTP
gateway once, or that once my reader gets an article, it does "re-get" it
if someone updates it. Not sure.


> The "simple" <cfset> expression, <cfset session.clientBalance =
> session.clientBalance - 99.50>, is actually an example of code that can
> result in a race condition. It therefore requires a lock.

My initial response to that is "no, actually: it's not". However I'm
always open minded (-ish). Can you pls explain how it is a race condition?

--
Adam

[BKBK]

> This would have been true in CF5. As per what Pete alluded to earlier, it
> has not been the case since CF6. Java automatically locks this sort of
> situation.
May be so, but it's not yet an exact science. You apparently presume that the line <cfset session.clientBalance = session.clientBalance - 99.50> exists in isolation. That is almost never the case in practice. There is usually other code in the way, often involved, some of it also in session scope. In fact, the relative delays here and speed-ups there are the main determinants of the race conditions between two request threads contending for the session code-block.

I've attempted to simulate an example.

1) Right-click on link 1 and Open in New Window. That begins the first request.
2) Immediately right-click on link 2 and Open in New Window.

The requests might represent transactions. Without the lock, the second request will run first. With a lock, the second request will always wait till the first finishes, which is what most account-updating code want.

[Newsgroup_User]

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>


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).

What your demonstrating with your example is that race conditions can arise
within a code BLOCK (my assertion), not a single STATEMENT (your assertion,
which I was correcting).

So... yes. We're in agreement. :-)

--
Adam

[Adam_Cameron]

Oh. That's just a terrible explanation, sorry, I was in a rush to get to the pub (or at least t my mate's place to drink beer, where - sadly - I am now, on the computer). It's not controlled @ CF-statement-level at all.

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.

But, yes, this does not help race conditions that crop up across code blocks (as per both our examples).

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.

--
Adam

[BKBK]

Assume the current value of session.clientBalance is 300. It is conceivable that two separate requests from the same session could simultaneously reach the line

<cfset session.clientBalance = session.clientBalance - 99.50>

The result would be:

session.clientBalance after Request 1: 200.50
session.clientBalance after Request 2: 200.50

That scenario would never occur when the exclusive lock is used. The client balance would then be 200.50 after one request, and 101 after the next.

[Newsgroup_User]

> Assume the current value of session.clientBalance is 300. It is conceivable
> that two separate requests from the same session could simultaneously reach the
> line
>
> <cfset session.clientBalance = session.clientBalance - 99.50>
>
> The result would be:
>
> session.clientBalance after Request 1: 200.50
> session.clientBalance after Request 2: 200.50
>
> That scenario would never occur when the exclusive lock is used. The client
> balance would then be 200.50 after one request, and 101 after the next.

This would have been true in CF5. As per what Pete alluded to earlier, it
has not been the case since CF6. Java automatically locks this sort of
situation. The only race conditions that one needs to be worried about is
where it is essential that nothing changes the value of a variable BETWEEN
TWO statements being executed, eg:

<cfparam name="session.inited" default="false">
<cfif not session.inited>
<!--- do some stuff that you don't want run unless session.inited is false
--->
<cfset session.inited = true>
</cfif>

So it's possible for one thread to hit the first line, and start initing
the session. And before that thread gets to the <cfset>, another thread
could hit the <cfif>, and commence the session-init code a second time.

THAT'S the situation you need to lock.

--
Adam

[BKBK]

> 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.

[Newsgroup_User]

> > 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.

No you didn't. You changed the lock to EXCLUSIVE. The fact that the lock
is there *at all* is what's incorrect.


> 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.

Yeah. It is. Well so close to one that when one is operating at the CF
level of things, it might as well be.


> 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.

[snort]

Nice sentence. Nice use of buzzwords. It doesn't *mean* anything though,
does it?


> This http://livedocs.macromedia.com/coldfusion/7/htmldocs/00001167.htm
> explains how and why to a single cfset.

The top section of that guidance is wrong. But fair enough if that's what
you were running with: one *should* be able to trust the docs.

The bit starting with "Ensuring consistency of multiple variables" is
correct, though.

I will pursue a correction for the top bit.

--
Adam

[BKBK]

> No you didn't. You changed the lock to EXCLUSIVE.
I only meant that you should not have repeated
the READONLY, two days after it is corrected. Its
presence confuses what follows.

> The fact that the lock is there *at all* is what's incorrect.
Can you see the absurdity in suggesting that the following code is
incorrect because it contains a lock?
<cflock scope="SESSION" timeout="3" type="EXCLUSIVE">
<cfset session.clientBalance = session.clientBalance - 99.50>
</cflock>

> [snort]
> Nice sentence. Nice use of buzzwords [atomicity, reentrancy, recursion].
> It doesn't *mean* anything though, does it?
Funnily enough, you've answered that question yourself. At least, partly. You write, a little later, "The bit starting with "Ensuring consistency of multiple variables" is correct, though." Well, that bit contains a word that is so important it is the only one highlighted in bold. It is the word atomic.

Recursive updating of a variable is good for thread-safety, however, not when it is a shared variable. The processor might decide to update its value in two or more steps (non-atomicity). If, Thread A is interrupted while it is updating the variable session.clientBalance, and Thread B updates the variable, will the value be consistent after Thread A resumes and finishes (reentrancy)? Those are issues that affect thread-safety. It is sufficient that some questions are raised.

None of them arises when you use a lock. Here, Java can speak for Coldfusion. Synchronization ensures that Thread A's update will be visible to Thread B. However, the only way to ensure consistency is for the synchronized code blocks to hold the same lock object. The general advice in the literature, for synchronized Java code as well as for Coldfusion, is to always use a lock (for often-updated shared variables) if the application is mission-critical. Think of code to update a bank account or code to dispense the drips going into a patient.