Shouldn't her/your code snippet instead be like:
<cflock scope="app" type="read"> <cfif isdefined("application.validateservice")> <cfset defined="1"> <cfelse> <cfset defined="0"> </cfif> </>
<cfif not defined> <cflock scope="app" type="excl"> ...application.createobject... </cflock> </>
That's unnecessarily complicated! :)
In the CF5 days, I got clarification from a CF engineer that the first cflock was required even to do just a "lookup" on the application scope for purposes of an isdefined(). Do you know of the status of this in CFMX? I can't imagine that it's allowed now.
CF5 needed thorough locking because failure to lock could lead to memory corruption and other nasty problems. In CFMX, you do not need to lock at all if you don't want to - you will not suffer memory corruption. In CFMX, you only need to lock if you wish to avoid "race conditions", i.e., to prevent two threads updating the same variable at the same time.
The code below checks for existence of the variable, unlocked, which is safe. However, two threads could both theoretically execute the test at the same time and both would 'succeed' on the cfif condition...
<cfif NOT IsDefined("Application.ValidateService")>
...hence the exclusive cflock that comes next, to ensure only one thread can move forward...
<cflock scope="Application" Timeout="10" THROWONTIMEOUT="No" Type="Exclusive">
...and then we re-test in single-threaded mode. We need to do this in case two threads executed the cfif above and one of them already got as far as initializing the variable before the other thread even got to the cflock.
<cfif NOT IsDefined("Application.ValidateService")> <cfobject component="#request.componentpath#ValidateService" name="Application.ValidateService"> </cfif> </cflock> </cfif>
Why do the cfif / cflock / cfif instead of just cflock / cfif? Because you do not want the overhead of calling cflock on every request. The vast majority of all requests will find the application variable already initialized - in fact only the first request to hit the server will find it uninitialized (modulo race conditions on the first few simultaneous requests!). By using an unlocked cfif, you place no locking overhead on subsequent requests.
I hope that clarifies things - locking strategies and multi-threading concerns are not straightforward!
Sean A Corfield -- http://www.corfield.org/blog/
"If you're not annoying somebody, you're not really alive." -- Margaret Atwood
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
