On Wed, Mar 18, 2009 at 01:06, Malcolm Tredinnick <malc...@pointy-stick.com> wrote: > There's no guarantee that the same session > will go to the same process (not to mention that the processes will stop > and start over time). > > If you're going to do something like this, it has to be external from > the web-process lifecycle and a centralised point that each process > talks to. Some kind of server daemon.
Doh, missed that! This would only work in a worker model, restricting deploy strategies. You're 100% correct. Some elaborate solution would be required. > At that point it becomes equivalent to just looking in the sessions > table for sessions that have already expired (which is a simple > queryset). (the server daemon in question is the database server, so the > pattern holds). > > I also don't think you're solving the original problem here (detecting > when a user who is coming back has an expired session, rather than never > been logged in) and detecting when sessions have expired can already be > done by looking at the database table. Based on this, I can't see why a simple custom cron job inspecting the pickled session data (assuming the user_id is in the session) before purging old session would not suffice. Care to elaborate? Cheers. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
