There's still questions about whether things should be <CFLOCK>'ed or not. This particular discussion happened on twitter where a developer was concerned that his session would bleed over into another user's session. To be clear, this was a major bug in the server. It happened back in the CF5 days. Suddenly there was a massive shift to get all the developers to cflock all of their session/application code. All of it. If it's not already obvious, there's performance rammifications behind this.

These days, 4, almost 5, versions later, gone are the days where you had to worry about session collision. Note, I'm not saying, don't use cflock. I'm saying, use them for an entirely different reason. Race conditions. If you have a session.user.isloggedIn and that's structure holding a boolean value and it should only ever be either true or false, but the timing of flip between true or false is important then you should be concerned which functions are messing with it. If there's a possibility that anything more than one function is flipping the value from true or false at any given moment, then you have the potential for a race condition.

From Wikipedia:
"A race condition or race hazard is a flaw in an electronic system or process whereby the output or result of the process is unexpectedly and critically dependent on the sequence or timing of other events"

The important part of this quote being: critically dependent on the sequence or timing.

By putting <cflock type="exclusive">, you're forcing other processes that are manipulating that session variable to wait in line via single threading. <cflock type="readonly"> allows mutli-threading reading of the variable so anything can get at it, except when it's busy being exclusive.

Also, cflock isn't exlcusive to sessions / applications. You may run into a process where you need a variable to be watched carefully (the internals of a cfobject as an example). Then, you use exclusive NAMED locks (e.g. <cflock name="somename" type="exclusive">).

As a side note, Application.cfc's onApplicationStart() / OnSessionStart() are already single threaded, you don't need to worry about cflocking. What you do need to worry about is if you have a restart configuration in OnRequestStart or OnRequest that re-initializes application / session vars by calling <cfset onSessionStart()> or <cfset onApplicationStart>, this is not thread safe and subjected to race conditions.

Cutter wrote on 01/16/12 1:22 PM

When you have those restart configs in OnRequestStart, you can wrap the calls in the lock (P.S. You can do this in script now too) to avoid issues:

lock scope="APPLICATION" type="exclusive" timeout="10" {
onApplicationStart();
}

Leave a comment