我有一个页面同时请求多个请求。所以这些请求都在同一个会话中。为了访问我到处使用的会话IHttpContextAccessor
.
我的问题是,无论时间如何,某些请求都看不到其他请求已经设置的会话状态,而是看到一些先前的状态。 (再次在时间上,设置状态操作已经发生了,仍然)
据我所知,每个请求都有自己的状态副本,该副本被写回...(以及“何时”?)到常见的“一”状态。如果这个“时间”是延迟到请求完全得到服务时,那么我遇到的情况很容易发生:会话中的第二个并发请求在第一个请求修改状态之后但在它完全完成之前获得了副本。
然而,这意味着在会话内并发请求服务的情况下,无法维护会话完整性。第二次没有看到第一次已经完成的更改,将写回与已经完成的第一次流程更改不一致的内容。
我错过了什么吗?
有什么解决方法吗? (当然需要一些费用)
首先,您可能已经知道这一点,但必须指出,以防万一:会话状态特定于一个客户端。那么,您在这里讨论的是同一个客户端同时抛出多个并发请求,每个请求都触及同一个会话状态。总的来说,这似乎是一个糟糕的设计。如果存在某种实际的应用程序原因,需要来自同一客户端的多个并发请求,那么这些请求所做的操作应该是幂等的,或者至少不会互相干扰。如果客户端只是因为不耐烦或恶意而向服务器发送垃圾邮件,那么您并不关心他们的会话状态是否因此而损坏。
其次,由于上述原因,并发性并不是会话真正关心的问题。我无法想象客户端需要发送多个同时请求且每个请求都修改相同会话密钥的用例。如果有,请通过相应地编辑您的问题来阐明。然而,我仍然认为这可能是你一开始就不应该在会议中坚持的事情。
也就是说,会话是线程安全的,因为多个同时写入/读取不会导致异常,但不能保证或不能保证完整性。这在所有并发场景中都是通用的。如果这是一个问题,那么作为开发人员,您有责任确保数据完整性。您可以通过设计并发策略来做到这一点。这可以是从锁/信号量到门禁的任何东西,或者只是补偿带外发生的事情。例如,使用 EF,您可以在数据库表中使用并发标记来防止一个请求覆盖另一个请求。每次成功更新时都会修改令牌的值,并且在进行更新之前会根据当前数据库值检查应用程序已知值,以确保自应用程序启动更新以来该值未被修改。如果有,则会抛出异常,以便应用程序有机会通过取消更新、获取新数据并修改它或只是推动覆盖来捕获和恢复。这是为了阐明,如果会话数据的完整性很重要,您将需要提出某种类似的策略。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)