I’m using sessions in Django to store login user information as well as some other information. I’ve been reading through the Django session website and still have a few questions.
From the Django website:
By default, Django stores sessions in
your database (using the model
django.contrib.sessions.models.Session).
Though this is convenient, in some
setups it’s faster to store session
data elsewhere, so Django can be
configured to store session data on
your filesystem or in your cache.
Also:
For persistent, cached data, set
SESSION_ENGINEto
django.contrib.sessions.backends.cached_db.
This uses a write-through cache –
every write to the cache will also be
written to the database. Session reads
only use the database if the data is
not already in the cache.
Is there a good rule of thumb for which one to use? cached_db seems like it would always be a better choice because best case, the data is in the cache, and worst case it’s in the database where it would be anyway. The one downside is I have to setup memcached.
By default,
SESSION_EXPIRE_AT_BROWSER_CLOSEis set
toFalse, which means session cookies
will be stored in users’ browsers for
as long asSESSION_COOKIE_AGE. Use
this if you don’t want people to have
to log in every time they open a
browser.
Is it possible to have both, the session expire at the browser close AND give an age?
If value is an integer, the session
will expire after that many seconds of
inactivity. For example, calling
request.session.set_expiry(300)would
make the session expire in 5 minutes.
What is considered “inactivity”?
If you’re using the database backend, note that session data can
accumulate in thedjango_session
database table and Django does not
provide automatic purging. Therefore,
it’s your job to purge expired
sessions on a regular basis.
So that means, even if the session is expired there are still records in my database. Where exactly would one put code to “purge the db”? I feel like you would need a seperate thread to just go through the db every once in awhile (Every hour?) and delete any expired sessions.
No.
That’s fine.
In some cases, there a many Django (and Apache) processes querying a common database.
mod_wsgiallows a lot of scalability this way. The cache doesn’t help much because the sessions are distributed randomly among the Apache (and Django) processes.Don’t see why not.
I assume you’re kidding. “activity” is — well — activity. You know. Stuff happening in Django. A GET or POST request that Django can see. What else could it be?
Put it in crontab or something similar.
Forget threads (please). It’s a separate process. Once a day is fine. How many sessions do you think you’ll have?