Hi everyone,
came across this today and it got me thinking:
What exactly is the rationale behind setting SESSION_ENGINE to django.contrib.sessions.backends.cache, as opposed to django.contrib.sessions.backends.cached_db, and being pretty explicit about telling deployers to not override this? (At least that’s how I read the big ### ALWAYS THE SAME ### warning, although people have evidently overridden this setting in the past.[1][2])
I understand that it wouldn’t scale very well to use just a database-backed session store without caching, but since Django does have one that does use write-through caching, I’m curious why that’s evidently being warned against.
I think (correct me if I’m wrong) that most Open edX users will be deploying with memcached-backed caches, and one generally expects to be able to restart those with impunity. Using the cached_db session backend would preserve user sessions across cache restarts (and across cache data eviction)[3], so I wonder whence the choice for defaulting to a session backend that does not?
I’m pretty sure I’m missing some obvious concern with django.contrib.sessions.backends.cached_db here, or maybe my assumptions about what caches people commonly use are wrong. Or maybe it is common to override SESSION_ENGINE after all?
If anyone would like to shed some light on this I’d be grateful. Thank you!