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.
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).
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?
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
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?
On Feb 25, 10:47 am, Jared Rypka-Hauer <[email protected]>
wrote:
> Arrays are passed byValue, but structures within an array are passed by
> reference... meaning that if you return an array you're actually returning a
> copy of the array, but each array element containing a structure contains a
> pointer to the same struct as the original. Ultimately, what this means is
> that if you return an array from a function and modify it, the original is
> not changed; however if you return an array of structures and change one of
> the structs, the original IS modified.
>
> Pseudocode isn't really going to be sufficient in this case as your problem
> is pretty unique.
>
> Oh, and not var-scoping your function-local variables creates them in the
> variables scope... which, depending on the function, can create some really
> nasty race conditions and/or memory leaks.
>
> Doing a deep copy with duplicate() does NOT RETURN ANYTHING BY REFERENCE...
> it's the only way to return a structure by value because it creates an
> entirely new structure that mirrors the original.
>
> Let's see... anything else?
>
> Oh, the fact that returning a struct from a CFC function in the application
> scope causes your app to return blanks pages pretty much tells me all by
> itself that the issue is your code and not CF. This is how all the major
> frameworks work, from Fusebox on up to ColdBox, so that's not the problem.
>
> J
>
> On Feb 25, 2010, at 11:39 AM 2/25/10, redtopia wrote:
>
> > ... It is true that arrays are passed by value (which sucks!!!). But I'm
> > pretty sure that structures within the arrays themselves are passed by
> > value, unless you do a deep copy using the duplicate method.
> > ...
--
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.
