RE: For the gurus: Question about state management with CLIENT sc ope
> Dave, is using the JSessionID a reasonable work > around (in Session scope)? Do we still need > CFID/CFToken (or URLToken) to be appended to > URL's or embedded in forms? If you use J2EE sessions - an option in the CF Administrator - then CF will generate and use JSessionID instead of CFID and CFTOKEN. They both work the same way, though; they can be set as cookies, but if not, they must be passed via the URL or via form submission. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm
RE: For the gurus: Question about state management with CLIENT sc ope
Dave, is using the JSessionID a reasonable work around (in Session scope)? Do we still need CFID/CFToken (or URLToken) to be appended to URL's or embedded in forms? == Peter Tilbrook Project Officer Strategic Development Australian Building Codes Board Department of Industry, Tourism and Resources GPO Box 9839 CANBERRA ACT 2601 AUSTRALIA E-Mail: [EMAIL PROTECTED] Telephone: (02) 6213 6731 Mobile: 0439 401 823 Facsimile: (02) 6213 7287 -Original Message- From: Stacy Young [mailto:[EMAIL PROTECTED]] Sent: Monday, 16 December 2002 1:10 PM To: CF-Talk Subject: RE: For the gurus: Question about state management with CLIENT sc ope I'm looking forward to replicated sessions on CFMX with J2EE...and hope they properly add the capability in Enterprise. As for client variables I still use them in some instancesas to whether there's a DB hit on every page...it may only happen when client values change. I remember doing a crude test a while back...had traces running on my SQL2K server...CF wasn't hitting the DB on every page load...appeared to be only when I was setting new values. Stace -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED]] Sent: Saturday, December 14, 2002 5:13 PM To: CF-Talk Subject: RE: For the gurus: Question about state management with CLIENT sc ope > > The Client scope isn't really intended to behave the > > same way as the Session scope - it's intended more > > for long-term user data storage, rather than storing > > data during an individual visit. > > It's intent is one thing. It's practicality is another. > > I never use session scope to maintain state. I use client > scope and store client variables in a database. I let the > database worry about what it is good at - locking, so I > don't have to worry about it. While this may ease your coding, especially with versions prior to CFMX, I would disagree with your implication that it's not practical to use the Session scope. It's pretty expensive to add a database query to every page, which is what you're doing when you use the Client scope. Storing short-term data in memory is much, much cheaper, and perfectly safe if you write your code correctly. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm
RE: For the gurus: Question about state management with CLIENT sc ope
I'm looking forward to replicated sessions on CFMX with J2EE...and hope they properly add the capability in Enterprise. As for client variables I still use them in some instancesas to whether there's a DB hit on every page...it may only happen when client values change. I remember doing a crude test a while back...had traces running on my SQL2K server...CF wasn't hitting the DB on every page load...appeared to be only when I was setting new values. Stace -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED]] Sent: Saturday, December 14, 2002 5:13 PM To: CF-Talk Subject: RE: For the gurus: Question about state management with CLIENT sc ope > > The Client scope isn't really intended to behave the > > same way as the Session scope - it's intended more > > for long-term user data storage, rather than storing > > data during an individual visit. > > It's intent is one thing. It's practicality is another. > > I never use session scope to maintain state. I use client > scope and store client variables in a database. I let the > database worry about what it is good at - locking, so I > don't have to worry about it. While this may ease your coding, especially with versions prior to CFMX, I would disagree with your implication that it's not practical to use the Session scope. It's pretty expensive to add a database query to every page, which is what you're doing when you use the Client scope. Storing short-term data in memory is much, much cheaper, and perfectly safe if you write your code correctly. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm
RE: For the gurus: Question about state management with CLIENT sc ope
Well guys, looking at the numbers in my app, I see I could reduce the 31ms spent maintaining state using client variables if I used session variables instead, but I would be much happier if I could reduce the 1625ms spent doing a full-text search using SQL7 by 10%. best, paul At 09:55 PM 12/14/02 -0800, you wrote: >As always Dave well stated, but good heavens it must be bloody late where >you are and Ah! CF1.5 I remember it well. > >Mike Brunt - CTO >Webapper Services LLC >Blog - http://www.webapper.net >Downey CA Office >562.243.6255 >AIM webappermb > >Web Application Specialists > >-Original Message- >From: Dave Watts [mailto:[EMAIL PROTECTED]] >Sent: Saturday, December 14, 2002 9:34 PM >To: CF-Talk >Subject: RE: For the gurus: Question about state management with CLIENT >sc ope > > > > My comment about "practicality" referred to client scope > > not to session scope. I was simply pointing out that it > > can be practical to use client scope. I did not mean to > > imply session variables were not practical. I was reacting > > to the suggestion that client scope was "intended more for > > long-term user data storage" I'm not exactly sure what the > > writer meant by this, but I didn't want the suggestion > > that client scope should not be used to maintain state > > to just lie there. > >Since I was the writer, I'll clarify if I can. > >Of course, Client variables can be used to maintain state - that is, in >fact, exactly what they do. And, yes, it can be practical to use Client >variables instead of Session variables, depending on circumstances. > >However, the Client scope persists beyond a single user's visit to the site, >by default, and is stored in a persistent data store by default as well. For >tracking a user's information during her visit to the site, Session >variables are generally more useful and efficient. Again, of course, this >isn't going to be true in all circumstances, but it will be true in most >cases. Session variables are stored in memory, so there's no database >overhead; you can store a significantly larger amount of data within the >Session scope before feeling any pain in the performance of your >application, as long as you have the memory to do so, and you can store >complex variables within the Session scope. > > > In the application I spend most of my time on, every > > page has database queries, and the ms spent on pulling > > client variables out of a database is not where the time > > is being spent. > >You are certainly paying some performance penalty for that single additional >query to the database. Just because every page has database queries doesn't >mean that you should tack one more on, unnecessarily. If you can trim ten >percent of your database time from every page, that's a significant >performance gain, and it'll show up as such during load-testing or >real-world load. > >Now, maybe, within your application it really doesn't make any difference; >maybe there isn't enough load on the application to make it matter, or maybe >there are other factors that make it more sensible to use Client variables >than Session variables. Nevertheless, if you had to make your application >perform better, that might be a good place to start. > > > In addition, I don't use the default client variable > > database storage method that requires parsing a > > #-delimited list to get each client variable. My client > > variable database has a specific column for each client > > variable. > >Well, then you're not using Client variables at all, are you? You're using a >similar method of your own construction (which is what we used to do in CF >1.5/2.0 days, since we didn't have Session variables back then). Again, >though, this extra database query is still going to increase the amount of >time your application spends talking to the database. In my experience, when >looking at how to increase application performance, the usual approach is to >improve (and minimize where possible) the amount and duration of database >interaction. > >I'd like to reiterate that this isn't a criticism of your specific >application design, just my opinion on general web application design >practices. > >Dave Watts, CTO, Fig Leaf Software >http://www.figleaf.com/ >voice: (202) 797-5496 >fax: (202) 797-5444 > > > ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm
RE: For the gurus: Question about state management with CLIENT sc ope
As always Dave well stated, but good heavens it must be bloody late where you are and Ah! CF1.5 I remember it well. Mike Brunt - CTO Webapper Services LLC Blog - http://www.webapper.net Downey CA Office 562.243.6255 AIM webappermb Web Application Specialists -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED]] Sent: Saturday, December 14, 2002 9:34 PM To: CF-Talk Subject: RE: For the gurus: Question about state management with CLIENT sc ope > My comment about "practicality" referred to client scope > not to session scope. I was simply pointing out that it > can be practical to use client scope. I did not mean to > imply session variables were not practical. I was reacting > to the suggestion that client scope was "intended more for > long-term user data storage" I'm not exactly sure what the > writer meant by this, but I didn't want the suggestion > that client scope should not be used to maintain state > to just lie there. Since I was the writer, I'll clarify if I can. Of course, Client variables can be used to maintain state - that is, in fact, exactly what they do. And, yes, it can be practical to use Client variables instead of Session variables, depending on circumstances. However, the Client scope persists beyond a single user's visit to the site, by default, and is stored in a persistent data store by default as well. For tracking a user's information during her visit to the site, Session variables are generally more useful and efficient. Again, of course, this isn't going to be true in all circumstances, but it will be true in most cases. Session variables are stored in memory, so there's no database overhead; you can store a significantly larger amount of data within the Session scope before feeling any pain in the performance of your application, as long as you have the memory to do so, and you can store complex variables within the Session scope. > In the application I spend most of my time on, every > page has database queries, and the ms spent on pulling > client variables out of a database is not where the time > is being spent. You are certainly paying some performance penalty for that single additional query to the database. Just because every page has database queries doesn't mean that you should tack one more on, unnecessarily. If you can trim ten percent of your database time from every page, that's a significant performance gain, and it'll show up as such during load-testing or real-world load. Now, maybe, within your application it really doesn't make any difference; maybe there isn't enough load on the application to make it matter, or maybe there are other factors that make it more sensible to use Client variables than Session variables. Nevertheless, if you had to make your application perform better, that might be a good place to start. > In addition, I don't use the default client variable > database storage method that requires parsing a > #-delimited list to get each client variable. My client > variable database has a specific column for each client > variable. Well, then you're not using Client variables at all, are you? You're using a similar method of your own construction (which is what we used to do in CF 1.5/2.0 days, since we didn't have Session variables back then). Again, though, this extra database query is still going to increase the amount of time your application spends talking to the database. In my experience, when looking at how to increase application performance, the usual approach is to improve (and minimize where possible) the amount and duration of database interaction. I'd like to reiterate that this isn't a criticism of your specific application design, just my opinion on general web application design practices. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting.
RE: For the gurus: Question about state management with CLIENT sc ope
> My comment about "practicality" referred to client scope > not to session scope. I was simply pointing out that it > can be practical to use client scope. I did not mean to > imply session variables were not practical. I was reacting > to the suggestion that client scope was "intended more for > long-term user data storage" I'm not exactly sure what the > writer meant by this, but I didn't want the suggestion > that client scope should not be used to maintain state > to just lie there. Since I was the writer, I'll clarify if I can. Of course, Client variables can be used to maintain state - that is, in fact, exactly what they do. And, yes, it can be practical to use Client variables instead of Session variables, depending on circumstances. However, the Client scope persists beyond a single user's visit to the site, by default, and is stored in a persistent data store by default as well. For tracking a user's information during her visit to the site, Session variables are generally more useful and efficient. Again, of course, this isn't going to be true in all circumstances, but it will be true in most cases. Session variables are stored in memory, so there's no database overhead; you can store a significantly larger amount of data within the Session scope before feeling any pain in the performance of your application, as long as you have the memory to do so, and you can store complex variables within the Session scope. > In the application I spend most of my time on, every > page has database queries, and the ms spent on pulling > client variables out of a database is not where the time > is being spent. You are certainly paying some performance penalty for that single additional query to the database. Just because every page has database queries doesn't mean that you should tack one more on, unnecessarily. If you can trim ten percent of your database time from every page, that's a significant performance gain, and it'll show up as such during load-testing or real-world load. Now, maybe, within your application it really doesn't make any difference; maybe there isn't enough load on the application to make it matter, or maybe there are other factors that make it more sensible to use Client variables than Session variables. Nevertheless, if you had to make your application perform better, that might be a good place to start. > In addition, I don't use the default client variable > database storage method that requires parsing a > #-delimited list to get each client variable. My client > variable database has a specific column for each client > variable. Well, then you're not using Client variables at all, are you? You're using a similar method of your own construction (which is what we used to do in CF 1.5/2.0 days, since we didn't have Session variables back then). Again, though, this extra database query is still going to increase the amount of time your application spends talking to the database. In my experience, when looking at how to increase application performance, the usual approach is to improve (and minimize where possible) the amount and duration of database interaction. I'd like to reiterate that this isn't a criticism of your specific application design, just my opinion on general web application design practices. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm
RE: For the gurus: Question about state management with CLIENT sc ope
Sorry, Dave. I guess I wasn't clear enuf. The original had "...it's intended..." referring to client scope. My comment about "practicality" referred to client scope not to session scope. I was simply pointing out that it can be practical to use client scope. I did not mean to imply session variables were not practical. I was reacting to the suggestion that client scope was "intended more for long-term user data storage" I'm not exactly sure what the writer meant by this, but I didn't want the suggestion that client scope should not be used to maintain state to just lie there. As always, conclusions are application-dependent. In the application I spend most of my time on, every page has database queries, and the ms spent on pulling client variables out of a database is not where the time is being spent. In addition, I don't use the default client variable database storage method that requires parsing a #-delimited list to get each client variable. My client variable database has a specific column for each client variable. best, paul At 05:13 PM 12/14/02 -0500, you wrote: > > > The Client scope isn't really intended to behave the > > > same way as the Session scope - it's intended more > > > for long-term user data storage, rather than storing > > > data during an individual visit. > > > > It's intent is one thing. It's practicality is another. > > > > I never use session scope to maintain state. I use client > > scope and store client variables in a database. I let the > > database worry about what it is good at - locking, so I > > don't have to worry about it. > >While this may ease your coding, especially with versions prior to CFMX, I >would disagree with your implication that it's not practical to use the >Session scope. > >It's pretty expensive to add a database query to every page, which is what >you're doing when you use the Client scope. Storing short-term data in >memory is much, much cheaper, and perfectly safe if you write your code >correctly. > >Dave Watts, CTO, Fig Leaf Software >http://www.figleaf.com/ >voice: (202) 797-5496 >fax: (202) 797-5444 > > ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm
RE: For the gurus: Question about state management with CLIENT sc ope
> > The Client scope isn't really intended to behave the > > same way as the Session scope - it's intended more > > for long-term user data storage, rather than storing > > data during an individual visit. > > It's intent is one thing. It's practicality is another. > > I never use session scope to maintain state. I use client > scope and store client variables in a database. I let the > database worry about what it is good at - locking, so I > don't have to worry about it. While this may ease your coding, especially with versions prior to CFMX, I would disagree with your implication that it's not practical to use the Session scope. It's pretty expensive to add a database query to every page, which is what you're doing when you use the Client scope. Storing short-term data in memory is much, much cheaper, and perfectly safe if you write your code correctly. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm
RE: For the gurus: Question about state management with CLIENT sc ope
An alternative point of view, the Session scope does have good practical usability and is significantly faster in most cases that constantly querying a database for each client request. We use this methodology in the ColdFusion applications where we use the Session scope. We write, read and changes all vars in the Request scope. in application.cfm: cflock timeout="30" throwontimeout="No" type="READONLY" scope="SESSION" cfset structappend(request,Duplicate(session)) /cflock in onrequestend.cfm cflock timeout="30" throwontimeout="No" type="EXCLUSIVE" scope="SESSION" cfset structAppend(session,Duplicate(request)) /cflock The one thing to watch for here is where Cflocation or Cfabort are used as the onRequestEnd.cfm file will not be run in that case and any variables created or changed in the current Request will not be in the Session scope the next time Application.cfm runs. We deal with this by including onRequestEnd.cfm directly before any Cflocation or Cfabort tags run. Kind Regards - Mike Brunt, CTO Webapper Blog http://www.webapper.net Web site http://www.webapper.com Downey CA Office 562.243.6255 AIM - webappermb Web Application Specialists -Original Message- From: paul smith [mailto:[EMAIL PROTECTED]] Sent: Saturday, December 14, 2002 9:49 AM To: CF-Talk Subject: RE: For the gurus: Question about state management with CLIENT sc ope It's intent is one thing. It's practicality is another. I never use session scope to maintain state. I use client scope and store client variables in a database. I let the database worry about what it is good at - locking, so I don't have to worry about it. best, paul At 04:54 PM 12/12/02 -0500, you wrote: >The Client scope isn't really intended to behave the same way as the Session >scope - it's intended more for long-term user data storage, rather than >storing data during an individual visit. ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm
RE: For the gurus: Question about state management with CLIENT sc ope
It's intent is one thing. It's practicality is another. I never use session scope to maintain state. I use client scope and store client variables in a database. I let the database worry about what it is good at - locking, so I don't have to worry about it. best, paul At 04:54 PM 12/12/02 -0500, you wrote: >The Client scope isn't really intended to behave the same way as the Session >scope - it's intended more for long-term user data storage, rather than >storing data during an individual visit. ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com
RE: For the gurus: Question about state management with CLIENT sc ope
Dave, That makes perfect since. Thats a great idea I didn't even think of it. I'm just suprised that the default behavior or CF Server is to drop permanent state cookies. I will do it manually and then I will be golden. Cool. Thanks, Jon -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 12, 2002 4:10 PM To: CF-Talk Subject: RE: For the gurus: Question about state management with CLIENT sc ope > I'm writing an app that uses the CLIENT scope for state > management. When somebody logs in, there are some "client" > variables that are set like CLIENT.firstName and CLIENT.lastName. > > The problem is that even if the end user quits the browser > after being logged in and comes back to the site 10 minutes > later, the user is still logged in from before. I realize > that you can set a timeout on client variables, but that > is stupid. The CFTOKEN and CFID need to go away when the > browser closes - just it it does on any other website I > can think of. The Client scope isn't really intended to behave the same way as the Session scope - it's intended more for long-term user data storage, rather than storing data during an individual visit. > How can I tell CF to set the CFID and CFTOKEN cookies as > 'session' cookies, meaning that they are gone when the > browser instance quits? It doesn't make any since for > people to still be logged in after they quit the browser > and it poses a mild security risk for what I'm trying to > do. I can think of some annoying work arounds but I can't > think of any elegant solutions for this problem. You can set the cookies yourself in Application.cfm: Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm
RE: For the gurus: Question about state management with CLIENT sc ope
> I'm writing an app that uses the CLIENT scope for state > management. When somebody logs in, there are some "client" > variables that are set like CLIENT.firstName and CLIENT.lastName. > > The problem is that even if the end user quits the browser > after being logged in and comes back to the site 10 minutes > later, the user is still logged in from before. I realize > that you can set a timeout on client variables, but that > is stupid. The CFTOKEN and CFID need to go away when the > browser closes - just it it does on any other website I > can think of. The Client scope isn't really intended to behave the same way as the Session scope - it's intended more for long-term user data storage, rather than storing data during an individual visit. > How can I tell CF to set the CFID and CFTOKEN cookies as > 'session' cookies, meaning that they are gone when the > browser instance quits? It doesn't make any since for > people to still be logged in after they quit the browser > and it poses a mild security risk for what I'm trying to > do. I can think of some annoying work arounds but I can't > think of any elegant solutions for this problem. You can set the cookies yourself in Application.cfm: Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm
