I think your locks may be the problem, you don't need to lock reads since J2EE
handles that shit.
I also think that this will be the 3rd or 5th time someone said (or at least
suggested) that pseudocode ain't gonna cut it here.
A couple inline comments:
J
On Feb 25, 2010, at 12:19 PM 2/25/10, redtopia wrote:
> Yes, I know that storing CFCs in a shared scope wasn't the problem.
> But I think my code exposed the memory leak bug in CF 8 that was fixed
> in one of the CF 8 hot fixes, though I haven't tested that theory. I
> solved the problem using the duplicate () function before I applied
> the hot fixes, so I don't really know.
If that were the case then your issues should have disappeared when you
installed the hotfix. Since they didn't, I revert to my previous statement, the
problem isn't CF, it's your code.
> Let me ask you this:
>
> You have a cfc that is stored in the application scope, and it stores
> an array as part of its instance data. It also has a method that
> changes the instance data (a refresh of the site map). And your
> application also allows a developer to re-create that cfc because a
> new version of that cfc might need to be applied to the application
> (obviously a rare action).
Are you hardcoding the site map into this CFC? Why? What purpose does any of
this serve?
> Somewhere in you code, you need direct access to the instance data (in
> this case to the site map data structure). Do you pass back a copy of
> the instance data, or do you allow direct access to the instance data?
Neither. You code thread-safe functions on that CFC to deliver to the page
whatever it needs, applying changes or receiving specific details.
> Here's what I do ( getSiteMap () returns a copy like this: <cfreturn
> duplicate (this.siteMapArray) /> )
>
> <cflock type="readonly" scope="Application" throwontimeout="true"
> timeout="30">
> <cfset siteMapArray = Application.siteMap.getSiteMap ()>
> </cflock>
>
> ... then the code uses siteMapArray to do what it needs to do
GET THE LOCKS OUT OF YOUR READS!! You do not need to lock reads to shared
scopes, but you need to lock writes. Use NAMED LOCKS (again) instead of
brute-force scope-wide locks.
> So I lock the application scope (to handle a situation when a
> developer would be re-creating the siteMap object), and then return a
> copy of the instance data.
>
> The code that handles when a developer would re-create the site map
> is:
>
> ... in onRequestStart
>
> <cfif (the developer wants to recreate the site map)>
> <cflock type="exclusive" scope="Application" throwontimeout="true"
> timeout="30">
> <cfset Application.siteMap = createObject ("component",
> siteMap).init ()>
> </cflock>
> </cfif>
>
>
> What do you think?
I think you have race conditions and thread-safety issues galore, and you're
not taking what advice has already been given:
var-scope everything
stop locking reads from shared scopes
use named locks instead of scope locks
Read up on thread-safety and CFCs, too:
http://www.compoundtheory.com/?ID=21&action=displayPost (old, but still
relevant)
http://corfield.org/blog/index.cfm/do/blog.entry/entry/CFCs_Scopes_amp_Thread_Safety
(ditto)
http://www.cfhero.com/2009/11/being-thread-safe-in-coldboxcoldfusion.html (a
bit simpler but much more recent)
--
You received this message because you are subscribed to the Google Groups
"CFCDev" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/cfcdev?hl=en.
