RE: Session variables

[Sam Dickerman]

Hi Y'all: We had this exact same problem a few months ago before we went live.  We use what I refer to as the "street-fighter" method of Spectra living.  We are a very low budget operation with the following hardware: PII 500 Webserver (NT 4.0) Shared SQL Server account on our ISP's unreliable SQL Server machine Thus, we don't just want, but NEED to keep database & processor overhead to a minimum.  Not that easy to do with Spectra. Here's what we did after asking these same sorts of questions. Near the top of our application.cfm file we have the following code:  **** = Comment **** Start a try cftry **** Set an exclusive lock (Note: all users must pass through this lock, which may be **** problematic if you are running  a BIG website.  But then you don't have our **** hardware issues : )  ) cflock timeout="5" name="Lockout" throwontimeout="Yes" type="Exclusive" **** By default the application variables have not been set cfparam name="Application.AppVariablesSet" default="0" **** If the application variables have not been set... cfif NOT Application.AppVariablesSet **** ...run THE REFRESHER,which sets all sorts of data into application scope cf_TheRefresher       ThingsToRefresh="All" **** Indicate that the application variables have been set cfset Application.AppVariablesSet = "Yes" /cfif **** End the lock /cflock **** If anyone timed out, we show them a page that says (in effect, but much **** nicer) "wait a sec while we refresh" cfcatch type="Lock" cf_lockedout cfabort /cfcatch **** End the try and that's it! /cftry So, every day in the early hours of the AM we have a scheduled page that first sets Application.AppVariablesSet = No, and then calls the homepage to trigger a refresh. As a result, we don't use locks anywhere else on the site!  That has saved me alot of coding and I would guess some processor overhead as well. Our site is very list intensive (we're a gay travel site www.guidemag.com) so we set tons of data into preformatted html chunks for rapid display on the site. As for true heavy load, we haven't come close (yet).  We get about 2000 visitors and about 25,000 page views a day. However, the site has been live for 3 months now and we've never had any trouble that I can see with the application variables and the refresh process. Hope that helps! Sam Dickerman Webmaster www.guidemag.com ----- Original Message ----- From: "David An" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, July 13, 2000 7:12 PM Subject: Fwd: RE: Session variables > > >From: Charles Teague <[EMAIL PROTECTED]> > >To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > >Subject: RE: Session variables > >Date: Thu, 13 Jul 2000 19:12:41 -0400 > >Reply-To: [EMAIL PROTECTED] > > > >Consider using the duplicate method that Ray suggests- copy the application > >variables to the request scope and reference those guys in line.  Then all > >you need is the initial locks for the write of the application variables and > >then a simple read lock around a duplicate function that moves those values > >into the request scope, which can be left unlocked.  We use this approach a > >lot internally with server scope, etc. . .   If you do no locking around the > >application variables, starting under load will probably crash the server as > >several requests will attempt to initalize those values. Good Luck- loving > >locking is the key to Zen stability and happiness under load! > > > >-c > > > >-----Original Message----- > >From: Raymond K. Camden [mailto:[EMAIL PROTECTED]] > >Sent: Thursday, July 13, 2000 3:38 PM > >To: [EMAIL PROTECTED] > >Subject: RE: Session variables > > > > > > From what I've heard, the risk is very minimal if you only do reads to your > >application variables. You should, of course, LOCK your initial writes. As > >it stands, I'd still considering locking your reads, just to be safe, but > >it's up to you. > > > >======================================================================= > >Raymond Camden, Cold Fusion Jedi Master for Syntegra (www.syntegra.com) > >Allaire Certified Instructor and Member of Team Allaire > > > >Email   : [EMAIL PROTECTED] > >ICQ UIN : 3679482 > > > >"My ally is the Force, and a powerful ally it is." - Yoda > > > > > > > -----Original Message----- > > > From: Alan Ford [mailto:[EMAIL PROTECTED]] > > > Sent: Thursday, July 13, 2000 1:23 PM > > > To: [EMAIL PROTECTED] > > > Subject: Re: Session variables > > > > > > > > > Hi Raymond, > > > > > > I like your sense of humour :-). > > > > > > Emily's message taught me some of the facts of life - now I know them all > > > :-). > > > > > > My reservation is the amount of work involved. On session variables, no > > > problem - I can now see the need and I will do the work. On application > > > variables we set a lot of things at the start of the app - such > > > as paths to > > > all sorts of things - different image directories, the secure server etc > > > etc. Whenever we display an image it's with code like <img src = > > > #application.imagepath#abc.gif> Wrapping all of those with cflock > > > will be a > > > lot of work. I'm happy enough to do it, but only if it's necessary. > > > > > > Our application.cfm only ever writes to these variables if one of them is > > > not defined (so we only ever do it once). After that we never, > > > ever, repeat > > > not a cat in hells chance, write to those application variables. In that > > > scenario, do I really have to wrap all references to application.xxx with > > > cflock, and if so can you quantify what the risk is? The variable cannot, > > > ever, change and it cannot, ever, not exist (since > > > application.cfm is run at > > > the start of every cfm page). I'm happy to cflock the setting of the > > > application variables, but I still can't see the need to lock the > > > reading of > > > them. > > > > > > Alan > > > > > > >--------------------------------------------------------------------------- - > >-- > >To Unsubscribe visit > >http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/spectra_tal k > >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/spectra_tal k > >or send a message to [EMAIL PROTECTED] with > >'unsubscribe' in the body. > > ------------------------------------------------- > David An: [EMAIL PROTECTED] > -- life through a browser -- > MINDSEYE Technology, Inc.   http://www.mindseye.com/ > >