Re: Using Cache+db for session backend

2008-10-14 Thread Jacob Kaplan-Moss

Hey Jessie --

See ticket #6791. It's got a well-written, working implementation; it
didn't make it into 1.0 because of time constraints. It'll almost
certainly make it into 1.1.

Jacob

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---



Using Cache+db for session backend

2008-10-14 Thread Jesse Young

I think it would be useful to include a session backend with Django
that stores session data in the cache and falls back to the database
if the session isn't in the cache. It's trivial to write your own
(mine is about 30 lines of code), but it seems like such a common use
case that it should just be in Django by default.

Currently there are three session backends: cache, file, and db. They
each have problems:

* The cache-based session store that ships with django
(django.contrib.sessions.backends.cache) is fast but seems essentially
useless because cache entries can be evicted at any time, and it isn't
very nice to require users to re-authenticate whenever that happens.

* The file-based session store
(django.contrib.sessions.backends.cache) would require a network file
system when deployed on a site that uses multiple web servers. (I'm
not sure about the relative performance of the file vs. cache
backends, but I assume that memcached would be faster than using a
network file system.)

* The database-backed session store
(django.contrib.sessions.backends.db) requires a database query every
time you retrieve the session. And for some sites, an extra query can
be prohibitive -- especially if it is the only query on the request,
which requires setting up a DB connection.

A cache+db session backend has pretty good performance in scenarios
when sessions are frequently accessed but infrequently modified, since
it basically acts like the cache backend except that when a session
gets evicted in the cache it can still be retrieved from the DB. Of
course that means that modifying the session is slower, since it needs
to be saved to both the cache and the DB. But I think there are many
use cases where the extra overhead on writes is not very significant.

Thoughts?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---