cflock and accessing session and application variables

[jqcf]

Is the information in this article still pertinent with Coldfusion 8?
http://www.adobe.com/devnet/server_archive/articles/cf_locking_best_practices.html

[Newsgroup_User]

jqcf wrote:
> Is the information in this article still pertinent with Coldfusion 8?
> http://www.adobe.com/devnet/server_archive/articles/cf_locking_best_practices.html

My understanding is that ALWAYS locking is now out-of-date advice.
There where bugs that caused performance issues if one did not lock
everything back in the 4.x days. But I have read that this has been
long resolved.

So the advice I advocate is to intelligently lock, when the application
logic requires it. I.E. Lock when there is a race condition and that
race condition can cause improper program execution.

The reason to not just lock everything, every time is that there can be
severe performance consequences to doing this. That article does give
some good advice on this to minimize the consequences. But why restrict
an application in such a way if it is unnecessary.

[Kling]

Hi all,
My boss wants to find out if our Coding Standards are out of date... they call for CFLOCKS for all calls of Session variables (EXCLUSIVE for cfsets, READONLY for anywhere one is referenced). Allaire (remember them?) recommended this a decade ago and we never updated it.

[Newsgroup_User]

Yup, that was advice that applied to the 4.x - Allaire versions of CF.
This standard is two companies and four versions (I don't know how many
updaters and hotfixes) out of date.

There are real performance and scalability issues to over use of
<cflock...> tags. The reason for doing so no longer apply. So I would
recommend updating your standard to only using <cflock...> when
requirements or logic require it.

[Kling]

Thanks!
But could you be more specific on "when requirements or logic" will require it? It would be really cool if you could point to something official from Adobe (I searched and couldn't find anything)

[Newsgroup_User]

in a nutshell, you need to lock a scope if there is a possibility of a
"race condition" - when more than one request may attempt to modify the
variable(s) in question at the same time.
IF and WHEN this race condition may occur depends on your application logic.
as a rule, WRITING to a shared scope should be locked, just to avoid any
possibility of a race condition...


Azadi Saryev
Sabai-dee.com
http://www.sabai-dee.com/

[Newsgroup_User]

Kling wrote:
> Thanks!
> But could you be more specific on "when requirements or logic" will require
> it? It would be really cool if you could point to something official from Adobe
> (I searched and couldn't find anything)
>

As Azadi said in his reply, the requirements would be when there is a
need to be concerned about "race conditions". This is a standard
computer science 201 programming logic concept and applies to all
languages, so Adobe doesn't really have anything 'official' to say about it.

The reason that back in the day, Allaire had this strong recommendation
was that there was an identified bug in the CF 4.x version where
unlocked, multiple thread reading and writing of shared scope variables
could cause memory leaks that would eventually destabilize the server.
This bug has been addressed as of version 5 so this is no longer a concern.

So now you only need to be concerned with your data and how multiple
users interacting with that data can affect your application. If there
is a concern where user A can change a shared variable and before user A
can use the proper value user B can change the value and this makes for
incorrect results; then you have a race condition and <cflock...> may be
appropriate.

A secondary use of the <cflock...> tag can be where you just want a
piece of code to be single threaded. I.E. a block of code should only
be run for a single user at any given moment. This is usually for
accessing some external resource that is not multi-thread safe.

Just be aware that this single-threading aspect of the use of the
<cflock...> tag can have an impact on the throughput and scalability of
your code. Too much of it on too large blocks of code can cause user
requests to start to pile up while each request waits its turn to run
through the locked block of code.