I have a possible race condition with an application scoped singleton. However, I thought that by defining a function level variable that this would not be a problem.
<!--- Calling page --->
<cfset url.UUID = createUUID() />
<cfset application.UUIDBot.displayUUID() />
<!--- UUIDbot --->
<cfcomponent>
<cffunction name="displayUUID">
<cfset var rc = {} />
<cfset rc.position 开发者_运维技巧= url.uuid />
<cfinclude template="displayUUID.cfm" />
</cffunction>
</cfcomponent>
<!--- displayUUID.cfm --->
<cfoutput>#rc.position#</cfoutput>
Is it possible that displayUUID.cfm would not display the UUID in the URL?
The problem is going to be found in the code you have not shared, that which is included via the displayUUID.cfm file. The code within the displayUUID is not thread safe (I am guessing). That code also needs to use "var" to localize the variables--or--prefix your references with "local." to ensure they are local scopped.
Bottom line: When you use cfinclude within a function the included code must also be thread safe.
I have read that implict struct notation itself is not thread-safe.
http://www.barneyb.com/barneyblog/2009/06/19/coldfusion-struct-literals-are-not-thread-safe-cfml-ones-are/
Try changing it to use a lock and a StructNew.
What you've posted there is thread safe. The issue of thread safety with structs occurs on assignment of a previously null pointed piece of memory. Since you're using the built in URL scope / struct which already has valid address space, this shouldn't be an issue.
You may however have issues with the logic and procedural execution timing.
That said, I do question the reasoning and design of what you have here. It raises a lot of red flags.
cfinclude? why? I fear you're going down the nasty road of dynamic includes.
精彩评论