I don't really understand what you're saying... but from what I think you're trying to suggest, I'd have to disagree with this concept.
Sessions simply allow information to persist between requests. Going into sessions and mangling them outside of the request is a very unique requirement that is often wholly unnecessary - and bad design. Walking through the entirety of sessions means analyzing and updating each one - including those that are dead / old / timed out. It's almost always much more efficient to update the information when needed. Many times in the past I've completed similar actions - across languages - with simple concepts: - result semaphores. an initial request starts a process for some sort of timed query or data update. when the request is finished, it sets a flag in the database or memcached. the server then just checks for the var - triggered by the url, timing, a session var, etc. - data timeouts. data is designed to timeout periodically or on command, and is then refreshed. - refresh semaphores. as you suggested, a "global variable that triggers session invalidation" is simple and does exactly what you need. most people will never want to or need to do this. if this is something that is built into your app - create routine/middleware that only executes within timed intervals, and can set/unset these variables as needed. - track sessions. you can also just externally track sessions. stick the beaker.session.id + userid in a database, and then delete the session. i'd just delete the entire session though - you run into race condition issues otherwise. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
