views:

193

answers:

3

I have used a version of double checked locking in my CF app (before I knew what double checked locking was)

Essentially I check for the exsistance of an object. If it is not present I lock (usually using a named lock) and before I try and create the object I check for exsistance again. I thought this was a neet way to stop multiple objects being created and stop excessive locking in the system.

This seems to work, in that there is not excessive locking and object duplicates don't get created. However I have recently learned that Double Checked Locking dosn't work in java, what I don't know if this holds true to CF, seeing as CF threads and locks are not quite the same as native java threads and locks.

+2  A: 

Java is threadsafe, so it isn't so much that your locks won't work as that they aren't necessary. Basically, in CF 6+, locks are needed for preventing race conditions or creating/althering objects that exist outside Java's control (files, for example).

Ben Doom
Actually I think they are necessary in preventing a race condition as Nathan describes.
Dan Roberts
@Dan Roberts: That is what I said.
Ben Doom
+5  A: 

To add on to what Ben Doom said about Java, this is fairly standard practice in ColdFusion, specifically with an application initialization routine where you set up your application variables.

Without having at least one lock, you are letting the initial hits to your web application all initialize the application variables at the same time. This assumes that your application is busy enough to warrant this. The danger is only there if your application is busy at the time your application is first starting up.

The first lock makes sure only one request at a time initializes your variables.

The second lock, embedded within the first, will check to make sure a variable defined at the end of your initialization code exists, such as application.started. If it exists, the user is kicked out.

The double-locking pattern has saved my skin on busy sites, however, with VERY busy sites, the queue of requests for the application's initial hit to complete can climb too high, too quickly, and cause the server to crash. The idea is, the requests are waiting for the first hit, which is slow, then the second one breaks into the first cflock, and is quickly rejected. With hundreds or thousands of requests in the queue, growing every millisecond, they are all funneling down to the first cflock block. The solution is to set a very low timeout on the first cflock and not throw (or catch and duck) the lock timeout error.

As a final note, this behavior that I described has been deprecated with ColdFusion 7's onApplicationStart() method of your Application.cfc. If you are using onApplicationStart(), then you shouldn't be locking at all for your application init routine. Application.cfc is well locked already.

To conclude, yes, double-checked locking works in ColdFusion. It's helpful in a few certain circumstances, but do it right. I don't know the schematics of why it works as opposed to Java's threading model, chances are it's manually checking some sort of lookup table in the background of your ColdFusion server.

Nathan Strutz
I understand the mechanism, but was surprised to learn that due to java’s' optimiser it won't work (see the link), what I didn't know is whether the reasons for it not working in java were also applicable to ColdFusion.
Jeremy French
A: 

To open a whole other can of worms...

Why don't you use a Dependency Injection library, such as ColdSpring, to keep track of your objects and prevent circular dependencies.

Steve -Cutter- Blades
Coldspring is not thread safe when getting beans (or at least didn't used to be) so that won't help.
Jeremy French
I wasn't aware of an issue. I've never run into problems myself. A quick Google shows a post from Brian Kotek discussing improvements in the 1.2 release, including "critical improvements in thread safety":http://www.briankotek.com/blog/index.cfm/2008/9/22/Whats-New-In-ColdSpring-12
Steve -Cutter- Blades