This is best done using j2ee sessions and the alternative managers available if you hunt google you will see SessionManagers for memcache etc already implemented i know of one for tomcat for example. Once its in memcache or a db if you choose easy for you to keep tabs and clear up as you see fit
A On 4 January 2012 19:57, Matthew Woodward <[email protected]> wrote: > 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 > -- Alex Skinner Managing Director Pixl8 Interactive Tel: +448452600726 Email: [email protected] Web: pixl8.co.uk -- 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
