> 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.
I solved the problem *before* I applied the hot fixes, so I'm not sure if it was CF or my code, but since the problem never happened on my development environment, even when load tested, (CF 9), and there's a hot fix that fixes memory leaks in cfcs in shared scopes, I figured it's a pretty good chance that it was the CF bug. That's not important anyway... what's important is that I figure out what "should" work, and then follow that method. > Are you hardcoding the site map into this CFC? Why? What purpose does any of > this serve? In my application, web site content is stored in a hierarchical data model inside a database. I construct a site map when the application is initialized so I can use it to do various sitemap related things, like building the site's menus, and displaying links to other pages within a section, or displaying the user's current location within the web site, etc... all the standard web site navigation stuff. Why do you think I have race/thread safety issues galore? Does it hurt to read-lock? If it's not necessary, I would assume that the underlying CF implementation amounts to a noop. I realize using named locks are better, and I use them a lot, but I lock the application scope whenever I write to it. Isn't that what I'm supposed to do? And I think a named lock can be disadvantageous for session scope data. In most cases, you wouldn't want to perform a named lock when you're writing to the session scope because that would lock any other request from other session from being executed for read-only access into that lock. Is that a correct assertion? Alternatively, locking the session scope, will only lock that specific user from read access, and not everyone else. Correct? Thanks for the links... I'll check them out. (FYI, I've been a CF developer for 11 yrs. and I have a CS degree, so you're not helping someone who is completely clueless!) On Feb 25, 11:53 am, Jared Rypka-Hauer <[email protected]> wrote: > 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_am...(ditto)http://www.cfhero.com/2009/11/being-thread-safe-in-coldboxcoldfusion....(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.
