On Wed, 2009-03-18 at 00:55 +0000, Paulo Köch wrote:
> Coder speaks louder. HTH.
>
> #Pseudo code. Not tested nor proven.
> class TimeoutTimerPool(object):
> """A pool that tracks a set of users and their active session.
> Tipically used as a singleton."""
> from threading import Timer
> def __init__(self):
> self.pool = {}
I'm hesitant to rain on your parade here, as you've put some effort into
writing a bunch of code. But the approach is flawed. As soon as you have
multiple processes involved (which is going to be normal), this
in-memory storage won't work. 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.
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.
Regards,
Malcolm
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
