Thread safety and the var scope — live example

Recently, I’ve talked to a few developers who knew about the var scope, but didn’t quite grasp the concept of making a variable local to a function. Additionally, I’ve come across a few posts that indicated that setting a var statement was strictly to conserve memory (along with other reasons that missed the point).

To help anyone struggling with understanding the impact of the var scope I’ve put together a quick example to demonstrate what can happen when you improperly scope a variable.

The example here focuses on CFCs that are loaded into a shared scope (session, application, etc), and are accessed simultaneously by multiple users.Running the code will make 2 simultaneous requests to the same function in separate iframes. The example contains a loop that outputs the index of a loop from 1 to 100. If the loop executes correctly the numbers appear in green, if the numbers are out of sequence, they will be red. To make the results more dramatic I’ve included a 1–40ms pause in each loop iteration.

Here’s the cfc that is loaded in server scope (simplified for reading). Note the only difference in the functions is that the “count” variable has a var statement in one function and doesn’t in the other function.

executing "nonVarFunction()"

		
		
			
			
			
			
				
				   
				   #count#
				
				   
				   #count#
				
			
			
		
	
	
	
		
		
		
		
		
		executing "VarFunction()"

		
		
			
			
			
			
				
				   
				   #count#
				
				   
				   #count#

What happened?

If the example executed correctly, you should have seen all green numbers in both windows for the var scope example, and a mix of green and red in the example that executed the function without the var statement. The presence of the “var” statement makes the variable local to the function. This means that when the function runs, it creates a new instance of the variable that is unique each time the function is executed. Without the var statement in place, the variable gets “shared” between everyone who is accessing this component. When a component lives in a shared scope (session, application) the variable will be shared for everyone accessing that scope. Think of the following scenario.

User 1: set count = 1

User 2: set count = 1

User 1: set count = count + 1

User 2: set count = count + 1

User 1: count = 2

User 2: count = 3

In this case the developer most likely intended to have both users see count = 2, however the variable was shared and as a result a user’s result was impacted by another user’s request. Note: this may be the intended behavior of the code, and that’s why there is no definite rule on why you should “always” or “never” var scope a variable.

Unfortunately, recognizing issues that appear as a result of improper scope can be difficult. Many times they result in server errors that are intermittent and only appear under load. This can sometimes make it practically impossible to reproduce the error in a test environment. Also, many tags create variables that are easy to miss (cfquery, cfloop, etc).

Luckily, there’s a tool to help (shameless plug here). Take a look at varscoper. Hopefully this will become an integral tool in your development process.