I too believe that
<cfset request.app = application.requestapp>
only sets a pointer. My question regards when do we need to set read locks?
When all application data resides in the database, and we establish that
application variables will only take on these values (and that no other
application variables will exists), then doesn't there exist an implicit
guarantee that (outside of Steve's code) only reads from the request
variable (a pointer to the application variables) will take place? Is there
any danger when two threads simultanously read from the same memory address?
-----Original Message-----
From: Cameron Childress [mailto:[EMAIL PROTECTED]]
Sent: Montag, 28. August 2000 15:33
To: [EMAIL PROTECTED]
Subject: RE: No more need for cflock!!
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.
------------------------------------------------------------------------------
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.
