On Mon, Jan 2, 2012 at 5:18 AM, Ivo Verbeek <[email protected]> wrote:
> I don't know exactly how this works "under the hood", but it sounds > almost like a seperate process which every X minutes take care of > cleaning the timed-out sessions. And a missing check if a session is > used again to see if it hasn't already timed out. > Sorry for the delay in getting back to you--I did some experimentation and confirmed with Andy that indeed there is a separate process that runs every 5 minutes to check for expired sessions. So in theory the longest you'd ever have to wait (meaning you hit it immediately after the session expiration process runs) for the session to expire would be 5 minutes. And of course if you hit it at the tail end of the cycle, you might see it times out "correctly" if you have a very low session timeout set. Andy's looking at the fact the CFID and CFTOKEN stay the same after expiration, but in my experimentation the session count definitely decreases after the session expires, increases again when I refresh a page with a session dump on it, but the ID and token stay the same. What DOES happen in that scenario is that after the session expires, any session data OTHER than the CFID and CFTOKEN does go away. So for example if a session starts and you do <cfset session.foo = "bar" /> then while the session is active if you dump the session, you'll see that variable in the dump. After the session expires the CFID and CFTOKEN will be the same as they were before, but session.foo will no longer exist. So in short the session does get expired, it just retains the same CFID and CFTOKEN. Ultimately you may, as Alex suggested, want to look into using J2EE session variables since those get nuked when you close the browser. > Which leaves the "client variables". Personally I like to use them > because I don't like the session-to-server binding in a load-balanced > environment. So if apps need to scale, I prefer to make them > sessionless. The two key questions here are 1) how much of an inconvenience it is for your users if their session gets lost (for some apps it's no big deal, for others it's crucial), and 2) would you be better suited looking into other means of scaling things out such as using memcache or another caching mechanism. > I understand the limitations of client variables over > sessions (only basic structures), but the session-in-database aspect I > like. But please tell me your opinion why to avoid using clients Main reason is because depending on where you store them of course it's a lot of extra overhead for (again, depending on the application in question) negligible benefit. This is a great summary of why they're generally not a good idea: http://www.dopefly.com/pages/ColdFusionClientVariablesFinalNail.cfm And honestly last I used them was on Adobe CF 7 and they absolutely didn't work as advertised, which caused major, major problems for the application I was working on at the time. You don't want customers logging in and seeing their competitor's logo instead of their own, for example. :-) > and > how do we solve that on load-balanced environments? > There's a million ways to skin that cat so it would be helpful to know more specifics about your application if you're interested in discussion some alternatives. > > What also comes out of this "testing" is that I now understand the > setclientcookies better. If I am not mistaken, I could disable > sessions and clients and still have > > <cfset this.setclientcookies = "Yes"> > > ... assign unique CFID&CFTOKEN cookies for visitors. Maybe build > alternative client management with that? > You *could* I suppose but you'd have to have a pretty compelling reason to roll your own IMO. -- Matthew Woodward [email protected] http://blog.mattwoodward.com identi.ca / Twitter: @mpwoodward Please do not send me proprietary file formats such as Word, PowerPoint, etc. as attachments. http://www.gnu.org/philosophy/no-word-attachments.html -- online documentation: http://openbd.org/manual/ google+ hints/tips: https://plus.google.com/115990347459711259462 http://groups.google.com/group/openbd?hl=en Join us @ http://www.OpenCFsummit.org/ Dallas, Feb 2012
