that's why you just whack the local copy of the variable back into the session scope (locking it, of course) at the end of processing.
ie, <CFLOCK READONLY> request.localstruct = Duplicate(SESSION.mystruct) </CFLOCK> .. processing on request.localstruct... <CFLOCK EXCLUSIVE> SESSION.mystruct = Duplicate(request.localstruct) </CFLOCK> christopher olive, cto, vp of web development cresco technologies, inc 410.825.0383 http://www.crescotech.com -----Original Message----- From: Sima Lee [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 13, 2001 8:50 AM To: CF-Talk Subject: RE: SUMMARY: Request Scope & Follow up Locking Questions Hi Terry, It's a very nice summary, however, I have some thoughts after reading. >A couple of notes here: if you do this, use something like > ><cfset request.var=Duplicate(session.var)> > >to transfer the variable. If you don't use Duplicate() - correct >me if I'm wrong someone! - then request.var just becomes a >'pointer' to session.var, and session.var is still actually read when >you refer later to request.var (rendering the whole business kind >of redundant!). Duplicate() - which is only available in CF4.5+ - >makes request.var a 'deep' copy of session.var, and then >request.var technically has nothing to do with session.var >except having the same value. And you said: "This gets to what I was really looking for because I want to do some things with structures and session variables and how best to work with them..." I think to use request.var this way you can only read the variable. Since the duplicate() function creates a new structure which copies the value of the seesion.var, any changes you made to it will not affect the actual session var(That's why you want a copy not a point). And the request.var will go out of scope after the current request, at next request you still make a copy to the actual session.var! This is just my thought if I am wrong please correct it. Thanks Sima -----Original Message----- From: Terry Hogan [mailto:[EMAIL PROTECTED]] Sent: Monday, November 12, 2001 12:46 AM To: CF-Talk Subject: SUMMARY: Request Scope & Follow up Locking Questions I want to thank everyone (particularily gyrus and Dave Watts) who responded to my questions regarding Request Scope. I had spent the better part of 2 days studying my 4 CF Reference Books plus checking many online sources and still didn't really understand the concept but you guys cleared it up real quick. I'm sure others are interested in this so I thought I'd summarize what I learned. Below I have cut&pasted some snippets from the thread and added a few of my own comments. 1. What exactly is the Request Scope? On 11/11/2001 at 3:59 AM gyrus wrote: >The request scope lasts for the duration of each request. If >you define request.var, every file (includes, custom tags, >whatever) that's processed from then on in the course of >that HTTP request has access to request.var. It seems kind of stupid now, but I couldn't understand why they were called "Request" variables. Daaaa! It's because they persist and are available to all templates and custom tags in a single HTTP request! On 11/11/2001 at 2:15 PM Peter Tilbrook wrote: >I may be wrong but once set (eg: in the application.cfm file) if you do not >provide a scope (eg: Application., Session., Client., they become variables >in the REQUEST scope. You can then access them anywhere in a template >without using a scope, eg: Hmmmm, but how does that fit with custom tags?...... On 11/11/2001 at 5:07 PM Dave Watts wrote: >It's identical to the local Variables scope in all ways except one: the >Request scope is available both to a page and to any custom tags called by >that page. It was added to make custom tag programming easier. If, for >example, you wrote a recursive custom tag, it might have to write to the >Caller scope to return its results, requiring a bit of tap-dancing around. >Using the Request scope, you can have a variable that can be accessed easily >from any custom tag, no matter how deep the recursion goes. Ok, that makes sense. And Peter wasn't quite correct. If a scope is not defined when a variable is set they are in the Variables Scope, not the Request Scope--the difference being that Request Variables are accessible (both Read & Write, I presume) in Custom Tags as well as the Calling template. 2. How are Request Variables similar or different from Session or Application Variables? On 11/11/2001 at 5:07 PM Dave Watts wrote: >They're not persistent memory variables, as are Session, Application or >Server variables. Goes back to my new found understanding that Request variables only last for a particular HTTP Request. 3. When should/shouldn't Request Variables be used? On 11/11/2001 at 5:07 PM Dave Watts wrote: >You can use them in place of the local Variables scope any time you like, >really. The only time it wouldn't be appropriate to use them this way is >when you want to create a variable that isn't accessible from both a calling >page and its custom tags. > >They're very useful as constants, for example. You might have a bunch of >variables which aren't going to change over the lifespan of the application, >things like DSN names and file paths, for example. The Request scope is good >for these since you may want to access those "global" variables from within >custom tags. Of course, when you use the Request or Variables scopes for >constants within Application.cfm, the variables will be created and >destroyed again for each page request. There's a cost to that, but it's >usually less than the cost of managing persistent memory variables within >the Application scope. Ok, but this had been one of my points of confusion. The "Books" tend to use the Session Scope to keep things like DSN names, etc. At first, I wondered if the Request Scope did not have persistance across sessions how would these variables be accessible on each request? Of course the answer is that the Application.cfm is called on each request. gyrus also had some comments on Request Scope usage leading into my last question about locking.... On 11/11/2001 at 3:59 AM gyrus wrote: >Request variables are often talked of just in the context of custom >tags, cos the fact that they can be accessed from anywhere >during one request means they're useful for custom tags to >talk to each other. But I use them quite a bit. I set all stuff >like DSN names and passwords in application.cfm using the >request scope. Also, any session variables that are needed >frequently, I transfer them to the request scope in application.cfm. >That way, I put one lock around this chunk of 'transfer' code, >and don't need to lock every time a session variable is needed. > >A couple of notes here: if you do this, use something like > ><cfset request.var=Duplicate(session.var)> > >to transfer the variable. If you don't use Duplicate() - correct >me if I'm wrong someone! - then request.var just becomes a >'pointer' to session.var, and session.var is still actually read when >you refer later to request.var (rendering the whole business kind >of redundant!). Duplicate() - which is only available in CF4.5+ - >makes request.var a 'deep' copy of session.var, and then >request.var technically has nothing to do with session.var >except having the same value. This gets to what I was really looking for because I want to do some things with structures and session variables and how best to work with them... My last question was: 4. What about locking? I've read that Request Variables don't need to be locked. Is that true? Why not? Dave Watts Replied.... >They don't need to be locked, because they're not persistent memory >variables. Ok, but what if you want to transfer Session Variables to Request Variables as gyrus mentioned above? What about Duplicate vs. StructCopy again, Dave Watts Replied.... >It's only necessary to use Duplicate in this case if Session.var is a >structure or a query. If it's just a simple value, you don't need to worry - >simple values are always passed by value, not by reference. The concensus seems that Duplicate() should be used when transferring Session Variables to Request Variables. Although there may be a slight performance hit, it keeps things consistent. Anyone, please feel free to correct or clarify my summation. Thanks again guys. Terry ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Get the mailserver that powers this list at http://www.coolfusion.com FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
