Everyone - please note the new thread name (we long ago left UDFs). Dave,
you wrote: >However, it's been my experience that, in most cases, this doesn't work very >well in the real world. Copying the entire scope into a local variable is >very expensive, and causes problems under load. We actually tried >implementing this in an application, but had to revert to the practice of >simply locking variables as appropriate within a page. I agree if you are writing to the session structure a great deal. However, if the variables in your session struct are fairly limited ( a 1 row query containing user information for example), and you rarely change what is contained in the session scope, copying them into the local scope (duplicate( )) can work pretty well. We have some aps with that scenario - we create a profile query when logging in so we can have some user specific information avaialble - then we copy it to the local scope with each subsequent request. We do NOT copy it back to the session scope at the end of each request as suggested (and I think that is where a penalty would ensue). Rather, when we need to update the session variable, we update it directly using CFLOCK. Under a high load the ap degrades gracefully and does not show any unexpected performance penalties - but again, we are basically doing a "read-only" to the sesssion struct. mark -----Original Message----- From: Dave Watts [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 19, 2002 9:28 AM To: CF-Talk Subject: RE: UDF question > Just a thought off the top of my head, > > Premise: Local Vars do not need to be cflocked > > Why not > > 1) copy the session structure to a temporary local > structure in Application.cfm: > > <cflock ...> > <cfset session_temp = structcopy(session)> > </cflock> > > 2) Reference the temp structure in all templates: > > <cfif isdefined("session_temp.blah")>... </cfif> > > 3) Set the session struct equal to the temp struct in > OnRequestEnd.cfm > > <cflock ...> > <cfset session = structcopy(session_temp)> > </cflock> > > I know this probably wouldn't work in the application scope > due to the execution time for each template: data might be > overwritten by multiple users; but in the session scope, it > seems to make sense. Many others have had this thought, to the degree that there's an example of this in the official Macromedia courseware ("Advanced ColdFusion Development"). However, it's been my experience that, in most cases, this doesn't work very well in the real world. Copying the entire scope into a local variable is very expensive, and causes problems under load. We actually tried implementing this in an application, but had to revert to the practice of simply locking variables as appropriate within a page. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ______________________________________________________________________ Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
