On Sat, Oct 27, 2001 at 05:48:54PM -0700, Quinn Dunkan wrote:
> 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?

I wouldn't do it that way.  The loop would be run on every hit.
Instead, I would subclass the session manager and override the new
session method to expire sessions if there are lots of them.

We have cron job that deletes sessions.  You need to have a DB that
allows concurrent access for this approach to work (we use ZODB with
ZEO0.

> (BTW, "del_sessions" seems deceptively named, because it just returns a list
> of ids that match the kwargs, it doesn't actually delete anything)

Oops, you're right.  Our session expire script doesn't use this method
but it probably should.  I'll fix that.

> 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.

We commit on every hit since our session data is important.  You could
make Session.commit only do a commit if a certain amount of time has
passed since the last commit.

> 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?

I don't think I know enough about your application to comment on that.
Your approach sounds slightly odd to me.  If you haven't already I would
suggest looking at ZODB.  It handles caching automatically for you.

  Neil