On Sat, Jan 19, 2013 at 3:03 PM, <testbackupa...@gmail.com> wrote: > If I'm reading the session docs correctly, if I add the data to the session > object, it'll get persisted, which I don't want.
i think you _do_ want it to be persisted. remember that HTTP is a stateless protocol. to have it even slightly scalable (anything beyond a handful of users), you have to realize that your sessions are longer than the request/response cycle, and can be handled by any one of several processes. that's why the session object saves its data to some backend. now, not every backend have to necessarily write to disk. i think you could simply use the memcached backend. > I believe I'll have the > same problem if I extend the user profile. And I *really* don't want to > store the data in the session cookie. not the same problem, but if you want session-long data, the best place to save it is on the session object. > For the time being, I'm just storing it in a global data structure in my > views.py, and deleting the data via a 'user logged out' signal. But I can't > seem to find a 'session timed out' signal to catch. And, anyway, I can't > shake the feeling that there's a better way to do this. Is there? that's definitely a bad idea. it will break down as soon as you use a non-single-process deployment. the session object is specifically thought to share data between not only from one request to the next, but also between the different processes that might handle it. tying the user to a single process creates a very low performance ceiling. -- Javier -- 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.
