Opinion: Abuse of session variables

I'm an old school programmer who watches every bit and byte and really practices resource management in my coding practices. I've got a new programmer working for me (on contract) and I'm finding he's using session Vars all over the place. He creating session Vars on forms that have a hundred fields, he putting arrays into session Vars, etc. I just went through a few of the programs he wrote and used them, then I dumped my session vars and found I had over 250 session vars from just using a few programs. Considering the site has over 1,000 users on it at any given moment, I'm very concerned about this practice. Am I nuts, or is this just bad? Thanks, Robert Robert B. Harrison Director of Interactive Services Austin & Williams 125 Kennedy Drive, Suite 100 Hauppauge NY 11788 P : 631.231.6600 Ext. 119 F : 631.434.7022 http://www.austin-williams.com Great advertising can't be either/or.  It must be &. Plug in to our blog: A&W Unplugged http://www.austin-williams.com/unplugged

"It depends." It could be no big deal, but it definitely sounds like there is a significant risk of "oops! there goes the server!". As a general rule, you are correct: keep the session as lean as possible. More specifically, don't use it unless there is a damn good reason to do so. Maybe it's time to have a "best practices" or "our standards are:" type of conversation. HTH On Tue, Jan 31, 2012 at 10:01 AM, Robert Harrison < robert@austin-williams.com> wrote: ----- Excess quoted text cut - see Original Post for more -----

As a general rule in life, I believe, everything in moderation - The extremes on either side will always get you into trouble. Modern servers have tons of RAM, session vars, especially vars that are just strings, are pretty light weight. It's hard to imagine making common senses use of them causing issues with the server. However, on the other side, if you got a guy storing every moment of every customer interaction in a session struct, you've got the definite potential for problems. Based on what you've told us, it sounds like this guy might have some architectural problems in his designs for you apps. I'd start with him by going over the realistic use cases for the data he is storing. It's likely he has a good reason for storing huge forms in the session(there are plenty of reasons to do that) - but maybe you need to look at how long those vals need to be persisted - if they need to be, I'd move them to a temp database and just carry a reference to the vals in the DB in their session. =] -- Alan Rother Manager, Phoenix Cold Fusion User Group, www.AZCFUG.org Twitter: @AlanRother

Thanks for all the input.  Besides the fact that the application could conceivably have hundreds of thousands of session Vars in memory, I'm concerned about collision too. I see no scope referencing in these Vars and see they are all 'common names'. I also see no routines to clear any vars after completion of an operation is over. Oh well. Robert B. Harrison Director of Interactive Services Austin & Williams 125 Kennedy Drive, Suite 100 Hauppauge NY 11788 P : 631.231.6600 Ext. 119 F : 631.434.7022 http://www.austin-williams.com Great advertising can't be either/or.  It must be &. Plug in to our blog: A&W Unplugged http://www.austin-williams.com/unplugged

I would agree with what some others have written, in that an apparent over-use of session variables is not inherently bad, unless it is causing server instability or memory problems. Make sure the programmer is using session variables for a specific reason, and that he is aware of the issues that using session variables can cause. Out of all the faults one can find when examining a Web site, using too many session variables is fairly low on the priority list. 1000 users on a site at a time with 250 session variables per user doesn't seem that bad to me on the surface. Storing frequently accessed database data in the session scope is often used as a caching optimization technique to reduce the database bottleneck. It is a technique I use and recommend, especially for very busy Web applications. In general, the busier the Web application, the more you are going to want to store in-memory to reduce the database usage, assuming your server has sufficient RAM. Really giant Web sites, like Facebook and YouTube, make extensive use of in-memory databases, like memcached. <http://en.wikipedia.org/wiki/Memcached>; One thing most developers neglect to do when using lots of session variables is making the session code thread safe, which takes a relatively high skill and experience level to accomplish. Unless you see a lot of cflock tags to mitigate the possible problems, a site with 1000 simultaneous users and 250 session variables might have random problems that could be traced back to the use of session variables. Threading problems can be hard to diagnose and are usually not discovered until the code gets put into a production environment. If the programmer is aware of the memory usage and threading issues, using lots of session variables is likely a minor concern, and potentially is a good thing if he is using them as a technique to speed up the Web application. You wrote "I see no scope referencing in these Vars," which I find odd if you are referring to variables in the session scope. All the in-memory variables should have their scope referenced when they are used. -Mike Chabot ----- Excess quoted text cut - see Original Post for more -----

> One thing most developers neglect to do when using lots of session > variables is making the session code thread safe, which takes a > relatively high skill and experience level to accomplish. Unless you > see a lot of cflock tags to mitigate the possible problems, a site > with 1000 simultaneous users and 250 session variables might have > random problems that could be traced back to the use of session > variables. This is largely false since the release of CF6. Race conditions being the primary exception. -Cameron ...

Race conditions are what I am referring to and they are a problem, even in CF9. Many developers either heard or read that the earlier problems with session variables have been fixed and that they no longer need to ever lock them, but this is not true. It is one of the most common CF misconceptions, even among experienced CF programmers. The problem generally only shows up on high-traffic data intensive sites, but even with 1000 simultaneous users and 250 session variables I would expect that the application will at some point have a seemingly random and rare issue when updating large structures of session variables or processing giant form submissions that could ultimately be traced back to a race condition where competing code execution process are accessing the same shared resource on different threads. The cflock tag still exists, and it is usually not used as frequently as it needs to be used, which is why I mentioned the problem. The use of the cflock tag is not simply a matter of preference. It solves an actual problem related to the multi-threaded code accessing shared resources, such as session variables. From the CF9 manual: "ColdFusion lets you lock access to sections of code to ensure that ColdFusion does not attempt to run the code, or access the data that it uses, simultaneously or in an unpredictable order. This locking feature is important for ensuring the consistency of all shared data, including data in external sources in addition to data in persistent scopes." I think many developers would prefer to ignore the issue because locking isn't fun and race conditions are a challenging issue to understand. -Mike Chabot On Wed, Feb 1, 2012 at 3:03 PM, Camer > This is largely false since the release of CF6. Race conditions being the > primary exception. > > -Cameron

Race conditions in session variables can only occur when two requests from the same session execute concurrently. This is more likely with ajax requests or framesets. Since everyone uses ajax requests these days (even though no-one uses framesets any more), it is still an issue, as you say. -- Shu Ha Ri: Agile and .NET blog http://www.bifrost.com.au/ On 2 February 2012 05:53, Mike Chabot <mchabot@gmail.com> wrote: > > Race conditions are what I am referring to and they are a problem, > even in CF9. Many developers either heard or read that the earlier > problems with session variables have been fixed and that they no > longer need to ever lock them, but this is not true.

In addition to AJAX (and Flex/Flash remoting calls) and framesets (and iframes), issues with session variables can also occur if a user has two separate browser tabs open, double clicks links or form submit buttons (some users double click everything), rapidly and repeatedly presses a submit button or the refresh button because a page is slow to load, submits a form, then makes a quick change before the form disappears from the screen, and submits again, requests a page but presses the browser back button before the page loads, rapidly toggles through multiple pages using a fast-loading navigation element (possibly controlled by a URL variable), starts running a page that takes so long to process that they hit the browser timeout before the code finishes processing, so they run it again, and likely some other scenarios. -Mike Chabot ----- Excess quoted text cut - see Original Post for more -----

> Race conditions in session variables can only occur when two requests from > the same session execute concurrently. This is more likely with ajax > requests or framesets. Since everyone uses ajax requests these days (even > though no-one uses framesets any more), it is still an issue, as you say. > This can be true, depending on the situation and how you are using the session scope. However, untrue is the old adage of "always lock your session variables". -Cameron -- Cameron Childress -- p:   678.637.5072 im: cameroncf facebook <http://www.facebook.com/cameroncf>; | twitter<http://twitter.com/cameronc>; | google+ <https://profiles.google.com/u/0/117829379451708140985>;

I'd also argue that sometimes race conditions may not matter. Consider a session variable that tracks the # of pages you have viewed in your session. If I pop open a new tab and start reloading them both like crazy, it's possible the values may end up borked. But do we care? No. If it's just a simple stat and it's not perfect, then I'd ignore the hassle of locking the write/reads. On Thu, Feb 2, 2012 at 7:11 AM, Camer ----- Excess quoted text cut - see Original Post for more -----

of course for a newbie that has no idea what a race condition is, in todays "PC" society they might take that as an insult :-) On Thu, Feb 2, 2012 at 3:22 PM, Raymond Camden <raymondcamden@gmail.com>wrote: ----- Excess quoted text cut - see Original Post for more -----

On Thu, Feb 2, 2012 at 10:22 AM, Raymond Camden <raymondcamden@gmail.com> wrote: > I'd also argue that sometimes race conditions may not matter. > On project I've worked on, this is true 99.9% of the time. > Consider a session variable that tracks the # of pages you have viewed > in your session. If I pop open a new tab and start reloading them both > like crazy, it's possible the values may end up borked. But do we > care? No. If it's just a simple stat and it's not perfect, then I'd > ignore the hassle of locking the write/reads. ...and this is a pretty unusual use case with all the analytics packages out there. Really, I have a pretty hard time thinking of a good use case with race conditions that goes beyond a contrived impractical example. Banking maybe?  Though in most cases I'd going to be doing much of that type of work in the DB and even if I'm not, it's probably going to be in a scope that doesn't live past a single request. Most of the examples I see are things that shouldn't be using the Session scope at all anyway. Of course, folks are free write their apps any way they want, but I just don't see it as a problem.  I very very very rarely lock (or have need to lock) session vars. I don't think I've  personally found reason in any project I've worked on since CF5. -Cameron -- Cameron Childress -- p:   678.637.5072 im: cameroncf facebook <http://www.facebook.com/cameroncf>; | twitter<http://twitter.com/cameronc>; | google+ <https://profiles.google.com/u/0/117829379451708140985>; ...

> ...and this is a pretty unusual use case with all the analytics packages > out there. Really, I have a pretty hard time thinking of a good use case > with race conditions that goes beyond a contrived impractical example. Someone on cf-talk had a race condition just last week, around their authentication process. Of course, it was because of how their code was structured, and probably didn't need CFLOCK to resolve. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ http://training.figleaf.com/ Fig Leaf Software is a Veteran-Owned Small Business (VOSB) on GSA Schedule, and provides the highest caliber vendor-authorized instruction at our training centers, online, or onsite.

> > ...and this is a pretty unusual use case with all the analytics packages ----- Excess quoted text cut - see Original Post for more ----- Race conditions certainly exist.  Specifically though, race conditions involving session variables which can be resolved using CFLOCK, are relatively uncommon. In my personal experience anyway... -Cameron -- Cameron Childress -- p:   678.637.5072 im: cameroncf facebook <http://www.facebook.com/cameroncf>; | twitter<http://twitter.com/cameronc>; | google+ <https://profiles.google.com/u/0/117829379451708140985>;

----- Excess quoted text cut - see Original Post for more ----- I'm not sure I'm disagreeing with you. Most race conditions that I see can be resolved without CFLOCK, but not all - specifically around components used during authentication/user initialization/etc. The primary reason for them seems to be that developers just don't think about concurrency. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ http://training.figleaf.com/ Fig Leaf Software is a Veteran-Owned Small Business (VOSB) on GSA Schedule, and provides the highest caliber vendor-authorized instruction at our training centers, online, or onsite

> I'm not sure I'm disagreeing with you. Most race conditions that I see > can be resolved without CFLOCK, but not all - specifically around > components used during authentication/user initialization/etc. The > primary reason for them seems to be that developers just don't think > about concurrency. Agreed. -Cameron -- Cameron Childress -- p:   678.637.5072 im: cameroncf facebook <http://www.facebook.com/cameroncf>; | twitter<http://twitter.com/cameronc>; | google+ <https://profiles.google.com/u/0/117829379451708140985>;

>Race conditions certainly exist.  Specifically though, race conditions >involving session variables which can be resolved using CFLOCK, are >relatively uncommon. > >In my personal experience anyway... +! In my experience anything that would really be effected by race conditions shouldn't be in session scope to begin with. Mary Jo

Fyi cf officially did away with need for manual locking some time ago. The only sitation where you need to lock now is where you have potential race conditions. Some folks still like to lock anyway though. Regards Russ Michaels From my mobile On 1 Feb 2012 18:57, "Mike Chabot" <mchabot@gmail.com> wrote: ----- Excess quoted text cut - see Original Post for more -----

> I've got a new programmer working for me (on contract) and I'm finding he's using session Vars all over the place. He creating session Vars on forms that have a hundred fields, he putting arrays into session Vars, etc. I just went through a few of the programs he wrote and used them, then I dumped my session vars and found I had over 250 session vars from just using a few programs. Considering the site has over 1,000 users on it at any given moment, I'm very concerned about this practice. Your primary concern should not be the memory usage implications of this practice, but the functional implications. What does it mean for the correctness of your application? Can you still navigate the site with multiple tabs opened if everything goes into the session scope or do you get weird results on some pages because session variables get overwritten from elsewhere? Only after you are certain the code is functionally correct memory optimizations come into play Jochem -- Jochem van Dieten http://jochem.vandieten.net/

I generally would keep the variable as long as you need it and no longer. If it's just needed for the request, there is no reason at all it should be in the session scope.  Performance is a concern, but so is data leaking from page to page.  If you're putting alot in session and not paying attention to the names then you may end up stepping on variables as you go. At the least, if they are needed for a multipart form (for example) then he should be clearing (structDelete()) the variables when they are no longer needed.  Better yet, put then in a struct in session and just nuke that struct when you're done with it.  IF you have: session.myform.firstname session.myform.lastname session.myform.phone Then when you are done just do a little structDelete(session,'myform') action and your session is all clean again. -Cameron On Tue, Jan 31, 2012 at 11:01 AM, Robert Harrison < robert@austin-williams.com> wrote: ----- Excess quoted text cut - see Original Post for more -----

I think I ran across that guy once (lol).  IMO, loading anything other the absolute minimum required info to identify a unique session into session variables is bad coding practice. ----- Excess quoted text cut - see Original Post for more -----

I have come across some similar code also, moving variables scope into sessions and back again for no reason. if the data has no reason to persist past the request then there is no reason to put it in session scope. the primary reason for doing it with forms is to persist the form data so users can come back later and their data is still there, such as when a form is split across multiple pages.. perhaps you could just ask him why he is doing it. ----- Excess quoted text cut - see Original Post for more -----

> I have come across some similar code also, moving variables scope into > sessions and back again for no reason. There's actually a reason why that might be, in some cases. Not a good reason, but a reason nonetheless. It used to be the case (CF 5 and earlier) that you had to worry about locking a lot more than you do now. So, people would do something like this: <!-- top of page --> <cflock scope="session" ...> <cfset variables.localsession = session> </cflock> ... do a bunch of stuff with those variables ... <!-- bottom of page --> <cflock scope="session" ...> <cfset session = variables.localsession> </cflock> Unfortunately, it didn't work very well in practice. > perhaps you could just ask him why he is doing it. I am not being sarcastic when I say this - this is a very good suggestion. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ http://training.figleaf.com/ Fig Leaf Software is a Veteran-Owned Small Business (VOSB) on GSA Schedule, and provides the highest caliber vendor-authorized instruction at our training centers, online, or onsite.

in the case I was referring to Dave, there was no locking, and it was copying all scopes into sessions (variables, url and form) and then back again so it really was for no good reason :-) however all programmers work different and have a tendency to slate the way others have done things, thus why I suggested it would be better to just ask him rather than make assumptions.Most of time we don;t have this option as the original developer has long since gone. ----- Excess quoted text cut - see Original Post for more -----

>  IMO, loading anything other the absolute minimum required info to identify a unique session into > session variables is bad coding practice. What does that mean? The absolute minimum required info to identify a unique session would be the session ID. Are you saying any other use of session variables is bad practice? If so, I'll have to disagree with that pretty strenuously. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ http://training.figleaf.com/ Fig Leaf Software is a Veteran-Owned Small Business (VOSB) on GSA Schedule, and provides the highest caliber vendor-authorized instruction at our training centers, online, or onsite

> I've got a new programmer working for me (on contract) and I'm finding he's using session Vars all over the place. He > creating session Vars on forms that have a hundred fields, he putting arrays into session Vars, etc. I just went through > a few of the programs he wrote and used them, then I dumped my session vars and found I had over 250 session vars > from just using a few programs. Considering the site has over 1,000 users on it at any given moment, I'm very concerned > about this practice. > > Am I nuts, or is this just bad? There are several possibilities: 1. You are nuts, and this is just bad. 2. You are nuts, and this is not bad. 3. You are not nuts, and this is just bad. 4. You are not nuts, but this is not bad. The problem is, we don't have enough information to answer your question. We cannot accurately determine whether you're nuts, or whether this is bad. There's nothing inherently inappropriate about storing arrays in session scope, or submitted form fields, etc. It depends (as Jochem pointed out) on what your application is intended to do, and the potential use-case scenarios around your application. While memory is limited, it's much more efficient to store things in memory rather than refetch them from a database - database interactivity is typically the most expensive portion of an application. If you had unlimited memory at your disposal, it would make perfect sense to just store everything in there until you absolutely have to write it to a persistent data store. But you don't have unlimited memory, so you have a balancing act. We all would need far more information than you've provided to tell you whether you're off-balance one way or the other. I will say this, though - there's a reason we have 64-bit servers nowadays. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ http://training.figleaf.com/ Fig Leaf Software is a Veteran-Owned Small Business (VOSB) on GSA Schedule, and provides the highest caliber vendor-authorized instruction at our training centers, online, or onsite.