views:

71

answers:

1

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_ENGINE to "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_CLOSE is set

to False, which means session cookies will be stored in users' browsers for as long as SESSION_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 the django_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.

+1  A: 

Is there a good rule of thumb for which one to use?

No.

Cached_db seems like it would always be a better choice ...

That's fine.

In some cases, there a many Django (and Apache) processes querying a common database. mod_wsgi allows a lot of scalability this way. The cache doesn't help much because the sessions are distributed randomly among the Apache (and Django) processes.

Is it possible to have both, the session expire at the browser close AND give an age?

Don't see why not.

What is considered "inactivity"?

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?

Where exactly would one put code to "purge the db"?

Put it in crontab or something similar.

I feel like you would need a seperate thread to just go through the db every once in awhile (Every hour?)

Forget threads (please). It's a separate process. Once a day is fine. How many sessions do you think you'll have?

S.Lott
For a big site with lots of users maybe you'd have a lot of sessions? I don't know what "crontab" is so I'll definitely look into that. I was also thinking that "activity" could mean updating or accessing the session.
JPC
@JPC: Define "big" and "lots" first. Then figure out how many sessions. They're not a big database burden. "activity" as in "accessing the session" would be exactly the same as any GET/POST request handled by Django -- what else could it mean?
S.Lott