Steve... We've been using this technique for some time now. I see that you
are traveling down same path now, so here are comments on what I've found by
doing this so far...
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. You can solve the problem by doing this instead:
<cfset request.app= Duplicate(application.requestapp)>
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've done some rudimentary load testing with this technique, and haven't yet
seen a serious issue with decreased performance, but as I've been adding
more and more data into the application scope for a current project I've
become more and more worried that the same test would yield different
results a second time.
I probably will hold off on the load testing for a bit longer till I get
finished stuffing everything I need to into the application scope, but does
anyone else have any comments for or against this?
-Cameron
--------------------
Cameron Childress
McRae Communications
p. 770-460-7277 x.232
f. 770-460-0963
> -----Original Message-----
> From: Steve Nelson [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, August 26, 2000 10:34 AM
> To: Fusebox
> Subject: No more need for cflock!!
>
>
> I've just hit upon a technique that would mean we only ever need to use
> cflock two times in a fusebox home application. This is for application
> variables, session and server variables would need to do the same too i
> imagine (personally i never use them)
>
> First I want to propose a new filename, qry_globals.cfm the point of the
> file is to store application wide queries, it would sit in the root
> directory of your home application. It would run queries from the
> database upon booting up the server then store the variables into
> memory. This massively reduces stress on the database, generally it's
> an excellent technique. The problem has been with cflock. people
> forget to use it and CF WILL blow up on you if you forget to use
> CFLOCK. So I figured out a way to bypass all the cflock nonsense and
> only require two cflocks in your entire application, which do very small
> tasks.
>
> Check this code out. It's wicked cool (Hal let me know how I did on my
> fusedocs, i'm just starting to get into them, and love 'em! :)
>
> <cfsetting enablecfoutputonly="yes">
> <!--- qry_globals.cfm --->
> <!---
> || I start by doing a check to see if the variable
> application.requestapp exists if this
> || variable exists then I set request.app=application.requestapp and I
> do not rerun any
> || application wide queries. If this variable does not exist I rerun
> all the queries
> || and set application.requestapp=request.app
> ||
> || Then anytime I want one of these values I call it as:
> request.app.queryname instead
> || of application.queryname. By doing this I no longer need to use
> cflock in anywhere
> || other than this file.
>
> || [EMAIL PROTECTED]
>
> ||
> -->
> <-- request.app - this is a copy of an application variable called
> application.requestapp
> ++> application.requestapp - this is where all application wide queries
> sit
> +++
> --->
> <cfset request.maindsn="valuemusiclocal">
> <cfapplication name="blbl"
> applicationtimeout="#createtimespan(0,1,0,0)#">
> <cflock name="#application.applicationname#" timeout="60"
> type="readonly">
> <cfif isdefined("application.requestapp")>
> <cfset request.app=application.requestapp>
> <cfset runrequest="no">
> <cfelse>
> <cfset runrequest="yes">
> </cfif>
> </cflock>
> <cfif runrequest>
> <cfset request.app=structnew()>
> <cfquery name="request.app.getstates"
> datasource="#request.maindsn#">
> select * from states
> where active=1
> order by state_name
> </cfquery>
> <cfset request.app.state_rows=structnew()>
> <cfloop query="request.app.getstates">
> <cfset request.app.state_rows[state_id]=currentrow>
> </cfloop>
> <cflock name="#application.applicationname#" timeout="60"
> type="exclusive">
> <cfset application.requestapp=request.app>
> </cflock>
> </cfif>
> <cfsetting enablecfoutputonly="no">
>
>
>
>
>
> <!--- dsp_address.cfm --->
> <!---
> || I'm demonstrating the use of a request.app variable, note that
> || I do not need cflock, and I do not need to rerun the getstates query
>
> || [EMAIL PROTECTED]
>
> ||
> -->
> <--
> ++> request.app.getstates - this is a query with all the states in it
> +++
> --->
> <select name="state_id">
> <cfoutput query="request.app.getstates">
> <option value="#state_id#">#state_name#
> </cfoutput>
> </select>
>
>
> Now that's a beautiful thing! eh?
>
> Steve
> ------------------------------------------------------------------
> ------------
> 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.
----------------------------------------------------------------------------
--
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.
------------------------------------------------------------------------------
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.
