Schley says, "Care should be taken when using CFSET to move complex data types like structures from one scope to another. This action does not really copy the structure from one scope to the other; it creates a pointer to the original object. This means that accesses to this new structure will be accesses to a shared scope variable if the original variable was shared scope, regardless of the new scope. The Duplicate( ) function can be used to copy the structure instead of creating a pointer to it."
means afaik request scope is at all times POINTING to shared scope, notanother request var with differnet content, so moving it back again to shared is just removing the pointer?? rgds Colm -----Original Message----- From: Robertson-Ravo, Neil (REC) [mailto:[EMAIL PROTECTED]] Sent: 17 October 2002 12:01 To: '[EMAIL PROTECTED]' Subject: RE: [ cf-dev ] Good/Bad? I moving the session struct to the request scope so I do not need lock any session vars on that particular page request (which could be a lot). I will then dupe them back into the session scope OnRequestEnd.cfm so they are back in shared scope. N -----Original Message----- From: Rich Wild [mailto:[EMAIL PROTECTED]] Sent: 17 October 2002 11:43 To: '[EMAIL PROTECTED]' Subject: RE: [ cf-dev ] Good/Bad? why would you do that? besides, you'll need to lock the original move to that scope. but I don't understand why you're trying to put the session scope into the request scope. you only need to move the contents of the session scope, not the entire scope. > -----Original Message----- > From: Robertson-Ravo, Neil (REC) > [mailto:[EMAIL PROTECTED]] > Sent: 17 October 2002 11:55 > To: '[EMAIL PROTECTED]' > Subject: RE: [ cf-dev ] Good/Bad? > > > unless yoou have moved them to the request scope for the period of the > read/write > > -----Original Message----- > From: Tom Smith [mailto:[EMAIL PROTECTED]] > Sent: 17 October 2002 11:50 > To: [EMAIL PROTECTED] > Subject: Re: [ cf-dev ] Good/Bad? > > > yes that's right all shared scopes must be locked when > writing and reading. > ----- Original Message ----- > From: "Rich Wild" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, October 17, 2002 11:29 AM > Subject: RE: [ cf-dev ] Good/Bad? > > > > sorry, I think I may be misunderstanding you. > > > > if you have a variable in a shared scope: > > > > session.myvar > > > > then you need to lock and read/write access to it. > > > > > -----Original Message----- > > > From: Robertson-Ravo, Neil (REC) > > > [mailto:[EMAIL PROTECTED]] > > > Sent: 17 October 2002 11:32 > > > To: '[EMAIL PROTECTED]' > > > Subject: RE: [ cf-dev ] Good/Bad? > > > > > > > > > thats poppycock :-p, > > > > > > If you have copied the session scope into the request scope > > > and you are > > > referencing your session vars as : request.session.myvar you > > > do not have > > > lock AFAIK > > > > > > you just have to copy the back into the session scope. > > > > > > N > > > > > > -----Original Message----- > > > From: Rich Wild [mailto:[EMAIL PROTECTED]] > > > Sent: 17 October 2002 11:15 > > > To: '[EMAIL PROTECTED]' > > > Subject: RE: [ cf-dev ] Good/Bad? > > > > > > > > > you need to lock all shared scope variable access. can't get > > > away from it. > > > > > > > -----Original Message----- > > > > From: Robertson-Ravo, Neil (REC) > > > > [mailto:[EMAIL PROTECTED]] > > > > Sent: 17 October 2002 11:25 > > > > To: '[EMAIL PROTECTED]' > > > > Subject: RE: [ cf-dev ] Good/Bad? > > > > > > > > > > > > so, all in all; the code I posted is wrong (in that it > > > doesnt actually > > > > alleviate the fact you need to lock!) > > > > > > > > -----Original Message----- > > > > From: Rich Wild [mailto:[EMAIL PROTECTED]] > > > > Sent: 17 October 2002 11:01 > > > > To: '[EMAIL PROTECTED]' > > > > Subject: RE: [ cf-dev ] Good/Bad? > > > > > > > > > > > > I used this method once - Russ suggested an idea for a tag > > > > that accepts a > > > > list of variable names and then it copies all the those that > > > > exist in the > > > > session scope into the request scope. > > > > > > > > I made it into a tag and it worked brilliantly, so that on > > > > each page I only > > > > needed to name the session or app vars that I needed > > > copying into the > > > > request scope for that page. > > > > > > > > eg: > > > > > > > > <cf_apptap vars="myvar1,myvar2,myvar3" scope="session"> > > > > > > > > would copy session.myvar1, session myvar2 and > session.myvar3 into > > > > request.myvar1 etc etc. > > > > > > > > on another page you might only need to request.myvar1 so you > > > > would just do: > > > > > > > > <cf_apptap vars="myvar1"> > > > > > > > > it saved duplicating everything all the time. > > > > > > > > > -----Original Message----- > > > > > From: Taz -=TT=- [mailto:[EMAIL PROTECTED]] > > > > > Sent: 17 October 2002 11:09 > > > > > To: [EMAIL PROTECTED] > > > > > Subject: Re: [ cf-dev ] Good/Bad? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks guys you have confirmed what I thought : it is > > > all over the > > > > > > place...the system is very poor and indeed needs a rewrite > > > > > but thats not > > > > > on > > > > > > the cards. > > > > > > > > > > > > what needs to be done is to copy the session variables into > > > > > the request > > > > > > scope to avoud locking them.... > > > > > > > > > > > > its a nightmare, it really is! > > > > > > > > > > Its not a bad thing to do... I tend to use this approach when > > > > > using session > > > > > variables instead of client. But I've never had so many that > > > > > I needed to > > > > > loop through all values in the scope. Usually I just stick a > > > > > few duplicate > > > > > ops in the app_globals.cfm > > > > > > > > > > <cflock ...blah...> > > > > > <cfscript> > > > > > Request.Whatever = Duplicate(Session.Whatever); > > > > > ... > > > > > ... > > > > > </cfscript> > > > > > </cflock> > > > > > > > > > > Of course you have to remember to write to the session scope > > > > > when you change > > > > > the values, but its way better to do it this way than > > > > > constantly locking > > > > > session read ops. Same goes for application scope if you're > > > > using it. > > > > > > > > > > Taz > > > > > > > > > > > > > > > -- > > > > > ** Archive: > > > http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/ > > > > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > For human help, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > -- > > > ** Archive: http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/ > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > For human help, e-mail: [EMAIL PROTECTED] > > > > -- > > ** Archive: http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/ > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > For human help, e-mail: [EMAIL PROTECTED] > > > > > > -- > > ** Archive: http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/ > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > For human help, e-mail: [EMAIL PROTECTED] > > > > -- > > ** Archive: http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/ > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > For human help, e-mail: [EMAIL PROTECTED] > > > > > -- > ** Archive: http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/ > > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > For human help, e-mail: [EMAIL PROTECTED] __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com -- ** Archive: http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] For human help, e-mail: [EMAIL PROTECTED] -- ** Archive: http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] For human help, e-mail: [EMAIL PROTECTED] -- ** Archive: http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] For human help, e-mail: [EMAIL PROTECTED] -- ** Archive: http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] For human help, e-mail: [EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.394 / Virus Database: 224 - Release Date: 10/3/2002 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.394 / Virus Database: 224 - Release Date: 10/3/2002 -- ** Archive: http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] For human help, e-mail: [EMAIL PROTECTED]
