首页 > 解决方案 > ASP Net Core 3 会话(状态)并发性和完整性

问题描述

我有一个页面同时请求多个请求。所以这些请求在同一个会话中。为了访问我到处使用的会话IHttpContextAccessor

我的问题是,无论时间如何,一些请求都没有看到其他请求已经设置了会话状态,而是看到了一些先前的状态。(再次在时间上,设置状态操作已经发生,仍然)

据我所知,每个请求都有自己的状态副本,该副本被写回......(以及“何时”?)到常见的“一个”状态。如果这个“何时”是延迟到请求完全服务的时间,那么我遇到的情况很容易发生:会话中的第二个并发请求在第一个请求修改状态之后但在它完全完成之前得到了他的副本。

然而,以上所有这一切意味着,如果在会话中提供并发请求,则无法保持会话完整性。第二个没有看到第一个已经完成的更改,将写回与已经完成的第一个过程更改不一致的内容。

我错过了什么吗?有什么解决方法吗?(当然有一些费用)

标签: asp.net-coresession-state

解决方案


首先,您可能已经知道这一点,但需要指出的是,以防万一:会话状态特定于一个客户端。那么,您在这里谈论的是同一个客户端同时抛出多个并发请求,每个请求都触及相同的会话状态。总的来说,这似乎是一个糟糕的设计。如果有一些实际的应用程序原因需要来自同一个客户端的多个并发请求,那么这些请求所做的应该是幂等的,或者至少不会相互影响。如果这是客户端只是因为不耐烦或恶意而向服务器发送垃圾邮件的情况,那么他们的会话状态是否因此而损坏真的不是您关心的问题。

其次,由于上述原因,并发性并不是会话真正关心的问题。我无法想象客户端需要发送多个同时请求的用例,每个请求都修改相同的会话密钥。如果有,请通过相应地编辑您的问题来说明。但是,我仍然认为这可能是您一开始不应该在会话中坚持的事情。

也就是说,会话是线程安全的,因为多个同时写入/读取不会导致异常,但不能保证或不能保证完整性。这在所有并发场景中都是通用的。作为开发人员,您有责任确保数据完整性,如果这是一个问题。您可以通过设计并发策略来做到这一点。这可能是从锁/信号量到门访问的任何东西,或者只是补偿带外发生的事情。例如,使用 EF,您可以在数据库表中使用并发令牌来防止一个请求覆盖另一个请求。每次成功更新都会修改令牌的值,并且在进行更新之前会根据当前数据库值检查应用程序已知的值,以确保自应用程序启动更新以来它没有被修改。如果有,然后抛出一个异常,让应用程序有机会通过取消更新、获取新数据并修改它,或者只是推动覆盖来捕获和恢复。这是为了说明如果会话数据的完整性很重要,您将需要提出某种类似的策略。


推荐阅读