#6791 closed (fixed)
Cached DB Session Backend
Reported by: | jhenry | Owned by: | Jacob |
---|---|---|---|
Component: | contrib.sessions | Version: | 1.0 |
Severity: | Keywords: | ||
Cc: | pytechd@…, jdunck@…, waylan@…, gabor@…, Peter Kese | Triage Stage: | Ready for checkin |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
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.
Attachments (5)
Change History (25)
Changed 14 years ago by
Attachment: | cached_db.diff added |
---|
Changed 14 years ago by
Attachment: | cached_db_with_documentation.diff added |
---|
Changed 14 years ago by
Attachment: | cached_db_docs_and_tests.diff added |
---|
Changed default session backend to cached_db. Changed docs to be betterer. ;-) Added tests.
comment:1 Changed 14 years ago by
Owner: | changed from nobody to Jeremy Dunck |
---|---|
Status: | new → assigned |
Changed 14 years ago by
Attachment: | cached_db_docs_and_tests-2.diff added |
---|
Last patch didn't include the actual code for cached_db backend. :-/
comment:2 Changed 14 years ago by
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.
comment:3 Changed 14 years ago by
Triage Stage: | Unreviewed → Ready for checkin |
---|
comment:5 Changed 14 years ago by
Cc: | pytechd@… added |
---|
comment:6 Changed 14 years ago by
Cc: | jdunck@… added |
---|---|
Owner: | changed from Jeremy Dunck to Jacob |
Status: | assigned → new |
comment:7 Changed 14 years ago by
Owner: | changed from Jacob to Jeremy Dunck |
---|---|
Status: | new → assigned |
comment:8 Changed 14 years ago by
Owner: | changed from Jeremy Dunck to Jacob |
---|---|
Status: | assigned → new |
comment:9 Changed 14 years ago by
milestone: | 1.0 → 1.0 maybe |
---|
comment:10 Changed 14 years ago by
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.
comment:11 Changed 14 years ago by
milestone: | 1.0 maybe → post-1.0 |
---|
comment:12 Changed 14 years ago by
Cc: | korpios@… added |
---|
comment:13 Changed 14 years ago by
Cc: | korpios@… removed |
---|
Changed 14 years ago by
Attachment: | cached_db.py added |
---|
Modified cached_db.py used to work with django-1.0-final
comment:14 Changed 14 years ago by
Version: | SVN → 1.0 |
---|
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.
comment:15 Changed 14 years ago by
Cc: | waylan@… added |
---|
comment:16 Changed 14 years ago by
Cc: | gabor@… added |
---|
comment:17 Changed 14 years ago by
Cc: | Peter Kese added |
---|
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.
comment:18 Changed 14 years ago by
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.
comment:19 Changed 13 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
Added documentation to patch against trunk