blocks|key|2699027|text|实际发生的情况:当同一个用户使用相同的会话键发出请求时，一个用户的会话被销毁了(即他们注销了，或者会话过期了)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2699028|发生这种情况的原因:例如，如果用户打开两个选项卡并在其中一个选项卡中登出，同时也从另一个选项卡发出请求，则可能会发生这种情况。如果这两种情况都是连续发生的，那么就会出现这样的错误。|2699029|您需要担心吗？：除非您在日志中看到了很多这样的事件，否则不会，在这种情况下会出现一些错误。如果你只发现错误一次，那就没什么好担心的了。|2699030|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

What actually happened: A user's session was destroyed (i.e., they logged out, or the session expired) while the same user made a request with the same session key. 

Why it happened: For example, it could happen if the user had two tabs open, and logged out in one of the tabs, while a request was also made from another tab. If both happened in quick succession then one would hit this error.

Do you need to worry about it?: Not unless you see lots of events like this in the logs, in which case there is something wrong. If you found the error just once, then it's nothing to worry about.

blocks|key|2031356|text|如果用户试图在“非活动”状态下登录，也会发生此错误。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2031357|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

This error can also occur if an user is trying to login when in 'inactive' state.

blocks|key|3479081|text|当运行django服务器的服务器用户(如果由不同的用户运行而不是根用户运行)对目录没有足够的权限时，可能会出现此问题。因此，服务器只具有读取和不写入的权限。可以使用linux命令编辑项目目录的权限：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3479082|chmod+u=rwx,g=rx,o=+/project_path|code-block|syntax|javascript|3479083|其中u指用户，g指用户组，o指他人。|3479084|可以使用ls的-d选项检查目录的权限，如下所示：|3479085|ls+-lhd+/
ls+-lhd+/etc
ls+-lhd+/etc/opt
ls+-lhd+/etc/opt/$DJANGO_PROJECT|3479086|如果用户可能已在并发请求中注销，也会发生此错误。|3479087|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|S|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|T|8|@]|9|@]|A|$]]|$1|K|3|L|5|D|7|U|8|@]|9|@]|A|$E|F]]|$1|M|3|N|5|6|7|V|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

This problem can occur when the server user (if running by a different user than root) running the django server hasn't enough permissions on the directories. 
The server therefore has only the permission to read and not to write. 
You can edit the permission of the project directory using the linux command :

<pre><code>chmod u=rwx,g=rx,o= /project_path
</code></pre>

where u refers to users, g to group of users and o to others. 

You can check the permissions of a directory with the -d option of ls, like this:

<pre><code>ls -lhd /
ls -lhd /etc
ls -lhd /etc/opt
ls -lhd /etc/opt/$DJANGO_PROJECT
</code></pre>

This error can also occur if the user may have logged out in a concurrent request.

blocks|key|2031436|text|这也可能发生，因为您将会话存储在虚拟缓存后端中。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2031437|例：|2031438|如果您已经将"DummyCache“配置为默认的缓存系统，或者如果您有指向虚拟缓存的SESSION_CACHE_ALIAS点，那么即使在请求响应周期之间，这些存储数据也有可能被删除。也就是说，您的请求到达Djagno服务器并正在积极处理。|offset|length|style|CODE|2031439|问题|BOLD|2031440|您的settings似乎处于任何可能的配置中。|2031441|案例A：|2031442|#+Possible+Current+Configuration+
CACHES+=+{
++++'default':+{
++++++++'BACKEND':+'django.core.cache.backends.dummy.DummyCache',
++++++++'LOCATION':+'unique-snowflake',
+++++}
}

SESSION_ENGINE+=+"django.contrib.sessions.backends.cache"|code-block|syntax|javascript|2031443|或|2031444|#+Another+Possible+Current+Configuration+
CACHES+=+{
++++"default":+{
++++++++"BACKEND":+"django_redis.cache.RedisCache",
++++++++"LOCATION":+"redis://127.0.0.1:6379/1",
++++++++"OPTIONS":+{
++++++++++++++"CLIENT_CLASS":+"django_redis.client.DefaultClient",
++++++++}
++++},
++++'cache_backend_for_user_session':+{
++++++++'BACKEND':+'django.core.cache.backends.dummy.DummyCache',
++++++++'LOCATION':+'unique-snowflake',
++++}
}

SESSION_ENGINE+=+"django.contrib.sessions.backends.cache"
SESSION_CACHE_ALIAS+=+"cache_backend_for_user_session"|2031445|溶液|2031446|我希望，现在您已经得到了解决方案，如果会话引擎依赖于缓存，最好不要将它们指向DummyCache。|2031447|您可以在缓存中使用SESSION_ENGINE与任何其他缓存的合并。|2031448|SESSION_ENGINE+=+"django.contrib.sessions.backends.cache"
SESSION_CACHE_ALIAS+=+"default"++#+or+comfortabley+anything+else
CACHES+=+{
++++'default':+{
++++++++"BACKEND":+"django_redis.cache.RedisCache",
++++++++"LOCATION":+"redis://127.0.0.1:6379/1",
++++++++"OPTIONS":+{
++++++++++++++"CLIENT_CLASS":+"django_redis.client.DefaultClient",
++++++++}
+++++}
}|2031449|(Redis是我的首选配置；您可以使用django.core.cache.backends.locmem.LocMemCache或django.core.cache.backends.memcached.MemcachedCache或任何其他选项。或者，如果您仍然想使用DummyCache，甚至可以将会话引擎从缓存更改为其他类似的东西|2031450|#+File+Based
SESSION_ENGINE+=+"django.contrib.sessions.backends.file"

#+Works+In+Combination+With++Current+Cache+and+Database,+fairly+persistant
SESSION_ENGINE+=+"django.contrib.sessions.backends.cached_db"+++

#+Cookie+Based,+Browser+Clearing+Will+lose+it.+
SESSION_ENGINE+=+"django.contrib.sessions.backends.signed_cookies"++|2031451|entityMap^0|0|0|7|A|16|J|0|0|2|0|2|8|0|0|0|0|0|0|2|0|12|A|0|9|E|0|0|J|19|1T|1F|3R|A|0|0^^$0|@$1|2|3|4|5|6|7|1D|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1E|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1F|8|@$F|1G|G|1H|H|I]|$F|1I|G|1J|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|1K|8|@$F|1L|G|1M|H|L]]|9|@]|A|$]]|$1|M|3|N|5|6|7|1N|8|@$F|1O|G|1P|H|I]]|9|@]|A|$]]|$1|O|3|P|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|Q|3|R|5|S|7|1R|8|@]|9|@]|A|$T|U]]|$1|V|3|W|5|6|7|1S|8|@]|9|@]|A|$]]|$1|X|3|Y|5|S|7|1T|8|@]|9|@]|A|$T|U]]|$1|Z|3|10|5|6|7|1U|8|@$F|1V|G|1W|H|L]]|9|@]|A|$]]|$1|11|3|12|5|6|7|1X|8|@$F|1Y|G|1Z|H|I]]|9|@]|A|$]]|$1|13|3|14|5|6|7|20|8|@$F|21|G|22|H|I]]|9|@]|A|$]]|$1|15|3|16|5|S|7|23|8|@]|9|@]|A|$T|U]]|$1|17|3|18|5|6|7|24|8|@$F|25|G|26|H|I]|$F|27|G|28|H|I]|$F|29|G|2A|H|I]]|9|@]|A|$]]|$1|19|3|1A|5|S|7|2B|8|@]|9|@]|A|$T|U]]|$1|1B|3|-4|5|6|7|2C|8|@]|9|@]|A|$]]]|1C|$]]

This can also happen because you store session in a dummy cache Backend.
eg :
If You have configured &quot;<code>DummyCache</code>&quot; as your default Cache system or if you have <code>SESSION_CACHE_ALIAS</code> points to dummy cache, There is a chance that, these sesion data can get deleted even in between your request response cycle. That is, Your Request reached Djagno server and is actively under processing.
PROBLEM
Your <code>settings</code> seems to be in any of this possible configuration.
Case A:
<pre><code># Possible Current Configuration 
CACHES = {
 'default': {
 'BACKEND': 'django.core.cache.backends.dummy.DummyCache',
 'LOCATION': 'unique-snowflake',
 }
}

SESSION_ENGINE = &quot;django.contrib.sessions.backends.cache&quot;
</code></pre>
Or
<pre><code># Another Possible Current Configuration 
CACHES = {
 &quot;default&quot;: {
 &quot;BACKEND&quot;: &quot;django_redis.cache.RedisCache&quot;,
 &quot;LOCATION&quot;: &quot;redis://127.0.0.1:6379/1&quot;,
 &quot;OPTIONS&quot;: {
 &quot;CLIENT_CLASS&quot;: &quot;django_redis.client.DefaultClient&quot;,
 }
 },
 'cache_backend_for_user_session': {
 'BACKEND': 'django.core.cache.backends.dummy.DummyCache',
 'LOCATION': 'unique-snowflake',
 }
}

SESSION_ENGINE = &quot;django.contrib.sessions.backends.cache&quot;
SESSION_CACHE_ALIAS = &quot;cache_backend_for_user_session&quot;
</code></pre>
SOLUTION
I hope, now you got the solution, If the Session Engine Depends On Cache, It is better not to point them to <code>DummyCache</code>.
You can use <code>SESSION_ENGINE</code> with cache with cobination of any other cache
<pre><code>SESSION_ENGINE = &quot;django.contrib.sessions.backends.cache&quot;
SESSION_CACHE_ALIAS = &quot;default&quot; # or comfortabley anything else
CACHES = {
 'default': {
 &quot;BACKEND&quot;: &quot;django_redis.cache.RedisCache&quot;,
 &quot;LOCATION&quot;: &quot;redis://127.0.0.1:6379/1&quot;,
 &quot;OPTIONS&quot;: {
 &quot;CLIENT_CLASS&quot;: &quot;django_redis.client.DefaultClient&quot;,
 }
 }
}
</code></pre>
(Redis is my preferred configuration; you can use <code>django.core.cache.backends.locmem.LocMemCache</code> or <code>django.core.cache.backends.memcached.MemcachedCache</code> or any other option.
Or even you can change Session engine from cache to something else like these if you still want to use <code>DummyCache</code>:
<pre><code># File Based
SESSION_ENGINE = &quot;django.contrib.sessions.backends.file&quot;

# Works In Combination With Current Cache and Database, fairly persistant
SESSION_ENGINE = &quot;django.contrib.sessions.backends.cached_db&quot; 

# Cookie Based, Browser Clearing Will lose it. 
SESSION_ENGINE = &quot;django.contrib.sessions.backends.signed_cookies&quot; 
</code></pre>

blocks|key|2699157|text|由于不同的原因，我也得到了这个错误:由于一个不同的问题，数据库处于只读模式。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2699158|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I also got this error for a different reason: The database was in read-only mode because of a different issue.

blocks|key|3479145|text|在我的例子中，结果证明是由于两个数据库服务器之间的复制延迟(在主RW+-从模式RO中)，因为我将一些请求路由到从服务器，以便在DBs之间执行负载分配。使用2台Redis服务器作为缓存引擎也发生了同样的事情，因为它们之间的复制延迟。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3479146|我们修复它，强迫会话请求到主服务器。|3479147|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

In my case turned out to be caused by replication delay between two database servers (in Master [RW] - Slave mode [RO]) because I was routing some requests to the slave in order to perform a load distribution amongst the DBs. Same thing happened using 2 Redis servers as cache engine because of the replication delay between them.

We fix it forcing session requests to the main server.

blocks|key|2699194|text|这个错误让我忙了几个小时，直到最后我发现我的数据库被锁定了，因为我没有保存对它所做的更改。保存数据解决了这个问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2699195|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

This error kept me busy for a few hours until finally I found out that my database was locked due to the fact that I had not saved the changes I made to it. Saving the data solved it.

blocks|key|2699278|text|如果您调用|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2699279|request.session.clear()|code-block|syntax|javascript|2699280|当会话存在时(因为它没有被使用或超时)。|2699281|如果会话正在使用，则可以通过检查和清除会话来解决该问题：|2699282|if+request.session:
++++request.session.clear()|2699283|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Q|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|R|8|@]|9|@]|A|$]]|$1|K|3|L|5|D|7|S|8|@]|9|@]|A|$E|F]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

This exception also happen if you call
<pre><code>request.session.clear()
</code></pre>
when on session exists (becuase it's not used or it's timed out).
It can be solved by checking and only clear the session if its in use:
<pre><code>if request.session:
 request.session.clear()
</code></pre>

blocks|key|2031602|text|在我的例子中，我将数据库文件(SQLite)打开到DB浏览器中。因此，对于随后的请求，这使得它被关闭。尝试停止连接到数据库的其他东西。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2031603|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

In my case I had opened my database file (SQLite) into a DB Browser. So, this made it be closed for subsequent requests.
Try to stop other stuff that are connected to your database.

blocks|key|2699343|text|当HDD上没有更多的空间时，使用AWS+EC2实例并清除帮助的空间时，也会出现类似的问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2699344|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

This can also happen when there is no more space left on the HDD, had a similar issue with an AWS EC2 instance and clearing the space helped

blocks|key|2699369|text|当您使用presistend+(这会复制数据库中的缓存)+(django.contrib.sessions.backends.cached_db)并删除数据库或刷新数据库中的所有数据时，可能会发生此错误。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2699370|这种情况发生在开发模式下，因为我使用的是坞-撰写，并且在入口点有python+manage.py+flush。我刚刚删除了刷新命令，因为它是不必要的。|2699371|entityMap^0|U|16|0|W|M|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|M|8|@$9|N|A|O|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|P|8|@]|D|@]|E|$]]]|I|$]]

This error can happen when you are using presistend cache (which makes a duplicate of the cache in the database) (<code>django.contrib.sessions.backends.cached_db</code>) and you delete the database or flush all the data inside it.
This happend for me in development mode as I was using docker-compose and had <code>python manage.py flush</code> in the entrypoint. I just removed the flush command as it is not needed.

I have a Python/Django app which sometimes has more than 100 users logged in. One day, I found this in Django error log:

<pre><code>The request's session was deleted before the request completed. 
The user may have logged out in a concurrent request, for example.
</code></pre>

Although the message is written in quite understandable English, I have no idea

<ul>
<li>what actually happened</li>
<li>why it happened</li>
<li>whether I need to worry about it</li>
<li>if yes, how can I prevent this from happening again</li>
</ul>

I found a question with almost same title but the difference is that I do not have anything about caching in my settings.

If you need any pieces of code, just please let me know in the comments.

Thanks for your time!

The request's session was deleted before the request completed. The user may have logged out in a concurrent request, for example

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我有一个Python/Django应用程序，它有时有超过100个用户登录。有一天，我在Django错误日志中找到了这个：The request's session was deleted before the request completed. The user may have logged out in a co...

问在请求完成之前，请求的会话被删除。例如，用户可能已在并发请求中注销。
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在请求完成之前，请求的会话被删除。例如，用户可能已在并发请求中注销。EN