test0908
/
django
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Fixed #33797 -- Prioritized cached database backend for cached sessions in docs. 

Co-authored-by: Adam Johnson <me@adamj.eu>
This commit is contained in:
J.V. Zammit 2022-10-07 09:39:35 +02:00 committed by GitHub
parent 749cd83e13
commit fa9ac16c13
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 18 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

37
docs/topics/http/sessions.txt
View File

@ -72,28 +72,27 @@ If you have multiple caches defined in :setting:`CACHES`, Django will use the
default cache. To use another cache, set :setting:`SESSION_CACHE_ALIAS` to the default cache. To use another cache, set :setting:`SESSION_CACHE_ALIAS` to the
name of that cache. name of that cache.
Once your cache is configured, you've got two choices for how to store data in Once your cache is configured, you have to choose between a database-backed
the cache: cache or a non-persistent cache.
* Set :setting:`SESSION_ENGINE` to The cached database backend (``cached_db``) uses a write-through cache --
``"django.contrib.sessions.backends.cache"`` for a simple caching session session writes are applied to both the cache and the database. Session reads
store. Session data will be stored directly in your cache. However, session use the cache, or the database if the data has been evicted from the cache. To
data may not be persistent: cached data can be evicted if the cache fills use this backend, set :setting:`SESSION_ENGINE` to
up or if the cache server is restarted. ``"django.contrib.sessions.backends.cached_db"``, and follow the configuration
instructions for the `using database-backed sessions`_.
* For persistent, cached data, set :setting:`SESSION_ENGINE` to The cache backend (``cache``) stores session data only in your cache. This is
``"django.contrib.sessions.backends.cached_db"``. This uses a faster because it avoids database persistence, but you will have to consider
write-through cache -- every write to the cache will also be written to what happens when cache data is evicted. Eviction can occur if the cache fills
the database. Session reads only use the database if the data is not up or the cache server is restarted, and it will mean session data is lost,
already in the cache. including logging out users. To use this backend, set :setting:`SESSION_ENGINE`
to ``"django.contrib.sessions.backends.cache"``.
Both session stores are quite fast, but the simple cache is faster because it The cache backend can be made persistent by using a persistent cache, such as
disregards persistence. In most cases, the ``cached_db`` backend will be fast Redis with appropriate configuration. But unless your cache is definitely
enough, but if you need that last bit of performance, and are willing to let configured for sufficient persistence, opt for the cached database backend.
session data be expunged from time to time, the ``cache`` backend is for you. This avoids edge cases caused by unreliable data storage in production.
If you use the ``cached_db`` session backend, you also need to follow the
configuration instructions for the `using database-backed sessions`_.
Using file-based sessions Using file-based sessions
------------------------- -------------------------