On 29 October 2001, Quinn Dunkan said: > My "DB" is simply a directory of pickles, but the "application state" > is also the state of various system files (mailboxes). It's important > that session be expired in a certain amount of time. If that directory of pickles is one pickle file per session, it sounds like you've got it easy. Write a script to walk the directory, looking at each pickle (heck, you don't even have to load it: you could probably just look at the mtime), and deleting "old" ones (for some definition of old). Run it periodically with cron, with a carefully chosen period. Eg. if you say "sessions older than 1 hour will be expired" and you run the script every 15 minutes, then a session could live to 1:14:59 before being expired. The problem with running every N hits, as Neil suggested, is that it could be quite a while before N hits elapse. This is true even if N == 1; as N decreases, the load on your server increases and the probability of sessions living on too long decreases. Maybe you could keep a data structure in your session manager that classifies sessions by age, so you don't have to be a big expensive loop over all sessions every N hits. Or, if you're not afraid of threads, you could run a session expiry thread. It would be just like that hypothetical cron job I mentioned, but with all the pitfalls and advantages (?) of threading. BTW, we make *no* promises about the thread safety of Quixote! Note in particular that the quixote.get_*() functions are thread-ignorant. > If someone forgets to log off, I'd like the system to log them off > after a well-defined period of time. I suspect someday Quixote's session management machinery should have some sort of support for this. Right now, I don't think the right solution is obvious, so it's better to have a few different approaches implemented in the wild, and see what works. > If I didn't store the user name in the url (which is another possibly > unusual thing about my approach: the namespace looks like > Root_object.username.user_subobjects where Root_object uses _q_getname > to map usernames to logged in user objects) then the next person would > *accidentally* log into someone else's account. Hey, another thing just occurred to me: you could expire sessions "on demand". Eg. user joe currently has a session open, and a request is received with that session cookie, you take a look at the current time and the time of the last request for that session. If more than 1 hour (or whatever), expire it. That's not a complete solution, because sessions that are genuinely walked away from (browser shut down, cookie lost forever) will never be touched again. But it means you could run your cron-based session expirer less frequently, and not worry about the window of time between "session theoretically should have expired" and "session actually expired by cron job". > I should have been clearer about the application---it's a web mail thing. My > personal opinion is that http is for web documents and IMAP and POP are for > email, but http is what They want and none of the existing programs out there > did what They wanted. > > Anyway, since I'm also forced to use the inefficient unix mailbox > format (have to get along with pine, you know) parsing a large mailbox > looking for message 500 and reorganizing messages is expensive. Have you considered Maildir? AFAIK even Pine works with it. I see lots of people on the Exim and ReiserFS mailing lists who are very happy with Maildir on ReiserFS for POP/IMAP servers. Maildir would unload a lot of your job onto the filesystem, and ReiserFS is specifically designed to take that kind of load. (A regular Unix filesystem would probably work just fine, unless you're talking tens of thousands of users with thousands of messages each.) It also means you don't have to be afraid of writing changes to disk, because deleting a file is a hell of a lot cheaper than rewriting a whole mbox. And you don't have to worry about the (potentially) long window between "user walks away from browser thinking their changes have been made" and "user's session expires and changes are written to disk". Greg