Cached DB Session Backend

[jhenry]

Right now, I consider the "cache" session backend to be broken, especially when used with the memcached session backend.

In a large memcached environment, servers enter and leave the memcached pool frequently. Each time this happens, the pool mapping changes and automatically logs users out (and loses their session data).

Attached is a new backend which is basically a copy of the DB session backend with a django.core.cache wrapper on accesses to the session data; all writes are write through to the database and cache and all reads come from memcache except in case of a memcache failure when it reads from the database.

[mcroydon]

Added documentation to patch against trunk

[Jeremy Dunck]

Changed default session backend to cached_db. Changed docs to be betterer. ;-) Added tests.

[Jeremy Dunck]

Last patch didn't include the actual code for cached_db backend. :-/

[Jeremy Dunck]

After talking with Jacob, I reverted the default session backend to DB; changing the default is controversial, and this should be a simple win for interested people.

Anyway, cached_db_docs_and_tests-2.diff is the best; I somehow managed to leave cached_db.py out of my prior diff.

[mrts]

Looks to be in scope for 1.0.

[Russell Keith-Magee]

Forgot to include an explanation with the status change: This isn't a bug, it's a completely new cache backend. It's a nice-to-have, but not essential.

[Aurelio Tinio]

Modified cached_db.py used to work with django-1.0-final

[Aurelio Tinio]

Hi, thanks for the patch. It was exactly what I was looking for but had to make minor changes in order to get it to work with django 1.0. Specifically added the must_create parameter for the save method and added a flush method that passes the session_key argument for deletion.

Sorry for not posting it as a diff, just wanted to quickly put this up for anyone that might find it useful.

[Peter Kese]

I am running a cron job every night to delete expired sessions.
How does this fit with the cached_db session store strategy?

I'd suggest to add some signals to the Session's save() and delete() functions and update the cache accordingly.

[Jeremy Dunck]

I think you're talking about reaping through a database query. Just as model delete signals don't fire when doing that, cache isn't cleared when deleting cached_db from with a database query. Firing a signal per model instance is about as slow as deleting a record at a time-- it defeats the purpose of doing the query rather than looping over queryset results.

Still, mass deletes are a frequent need. I guess there could be a mass invalidation method, but I don't see a good place to do that.

[Jacob]

(In [9727]) Fixed #6791: added a write-through cache session backend: session data is written through the cache to the database, but read from the cache for speed. Thanks to jhenry, mcroydon, and jdunck.

[(none)]

Milestone post-1.0 deleted