> One mistake I made early on was code similar to this line from your code
> below:
>
> <cfset request.app=application.requestapp>
>
> I believe that this actually only creates a pointer to your application
> struct, so when you call something in 'request.app', it's still
technically
> accessing data in your application scope, and could still lead to memory
> issues without a lock.
That's exactly the point that I was going to raise. CF passes simple data
types (strings and whatnot) by value and complex data types (structures,
queries, etc) by reference.
> You can solve the problem by doing this instead:
>
> <cfset request.app= Duplicate(application.requestapp)>
Anyone running CF 4.01 might be tempted to run
StructCopy(application.requestapp) since Duplicate() is new to 4.5.
However, don't forget that if you have nested structures (and maybe even
other complex data types nested in a struct, like in Steve's example)
StructCopy() only copies the top level by value; nested objects are copied
by reference still.
> Also, I am very concerned about the effect of this method on a site which
> stores a large amount of data in the application scope. You're basically
> making CF copy the entire scope on every page call. This could cause
> enormous performance problems on a large, heavy traffic site with alot of
> data kept in memory.
I prefer to have my individual query modules handle their own locking. This
way, large queries maintained in memory are not duplicated for pages that
aren't going to use that query. I haven't done any real load testing to see
if there is a difference, so I'd be interested in any other data you turn
up.
Regards,
Seth Petry-Johnson
Argo Enterprise and Associates
------------------------------------------------------------------------------
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
