On Wed, Jan 4, 2012 at 11:07 AM, Ivo Verbeek (Ritense) <[email protected]>wrote:
> > 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. > > Sorry, this is where I do not agree. Then I'm not seeing the same thing you are. I tested that quite a bit and worst case after 5 minutes the session data would disappear. When I wait longer, 5+ minutes, I reload, I then see > the onSessionStart being triggered and session.start is fresh. CFID & > CFTOKEN are indeed unchanged. > If I'm understanding what you're saying, that's the expected behavior. The 5 minute cycle is independent of the session start time, i.e. it's for the server as a whole. So you would never necessarily see your session timing out after 5 seconds. It would only happen if the timing of the start of your session was right before the session expiration job ran. > > I still have to think that there is a bug: timed-out sessions who are > still in memory and re-used, are not checked to see if they are timed > out. But they are checked and do expire, just not with the level of precision I think you're expecting. > If they still exist, they are being re-used. Just to clarify, the "they" here is the CFID and CFTOKEN, but other session data does get wiped out. And my guess (although I haven't confirmed) is that it's just reusing the values from the cookie, it's not anything retained in memory. > I depends on the > other process to actually clear them from server memory. And that > process is the one and only that looks at the time-out value. > That's correct. > But openBD > system info shows "0 active sessions" .... I guess that > is not working for J2EE sessions. > Please file that as a ticket for us to look into if you don't mind--I'm calling a function in the engine from the admin console that reports active sessions so it may be the function needs to take J2EE sessions into consideration. http://code.google.com/p/openbluedragon/issues/list That article makes a lot of sense. Thanks for that. But even the > author doesn't think they are useless, it is just that the way they > are implemented is crap. Ergo they're useless. :-) I'm half-joking but this does tend to be one of the few areas where I take a pretty hard line simply because I don't think they're a good solution for the problems most people use them to solve. > Well, wouldn't it be a nice one for openBD to > do it better then :-) So not client vars as Adobe does them, but > really as session-in-database like e.g. give more control when and how > they are actually being read and especially write. Which more like > sessions, but then sessions-in-database. And only when you actually > define them and not always. > I'd be curious to hear more about what you have in mind--it might be interesting to, as with client variables, be able to define a storage location for session variables for the application so when you access session variables the machinery behind the scenes goes to the appropriate place (RAM, memcache, database, etc.) to get the data. The tricky part of course is dealing with complex objects though those could of course be serialized/deserialized as needed (or perhaps something specific and appropriate to each datastore type could be implemented). Something worth looking into perhaps. -- 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
