durusmail: quixote-users: new user, and session questions
new user, and session questions
2001-10-27
2001-10-29
2001-10-29
Non-reentrant functions in Quixote
2001-10-29
2001-10-29
2001-10-29
2001-10-29
new user, and session questions
Quinn Dunkan
2001-10-27
Hello, I'm new to the list.  I've been messing with Quixote for the last week
or so, and so far I think it's pretty cool.  I hacked on Bobo a while back, so
it feels like a cleaned up Bobo.

I have a few questions about sessions.  It looks like if I want sessions to
time out, I should override SessionManager.set_session_cookie to include an
expires attribute in the cookie, and then run

for s in get_session().values():
    if s.get_access_age() > timeout:
        del get_session()[s.id]

in the _q_access method of the root object.  Is this the right way to do it?
(BTW, "del_sessions" seems deceptively named, because it just returns a list
of ids that match the kwargs, it doesn't actually delete anything)


The other question is about session persistence.  It looks like the way to
implement persistent sessions is to override Session.commit to dump a pickle
or something.  I'd like to avoid having to touch the disk after every http
request (that's what FCGI is for, right?), so it doesn't seem to be quite what
I want.  Of course, what I want also implies I can only run one FCGI process
(unless FCGI has session affinity), but that's ok by me.  I plan on putting
I/O bound precaching processes in their own thread anyway.

How I'm currently doing things is that the user object stores varous caches
(just references to lazy lists).  When the session is expired,
req.session.user.close() is called, which writes the cached changes back to
their (locked, for coherency) originals (both generating the caches and
writing the changes is quite expensive) and pickles its persistent state.
When a new user object is created, it gropes around for the pickle, and
initializes its various sub objects with the pickle contents.  Presumably I
could put 'close()' in the __del__ method, but I'd like to avoid those since
they always seem to get run at the wrong time (e.g. when __init__ throws an
exception and the object is half-constructed).

So anyway, persistence is handled entirely by the user object, and Session has
nothing to do with it at all.  Once again, is this the right way to do things?
Or am I solving the problem in the wrong place?


thanks!


reply