ASP Net Core 3会话(状态)并发性和完整性 [英] ASP Net Core 3 Session (state) concurrency and integrity

问题描述

我有一个页面，可以同时请求多个请求.因此，这些请求在同一会话中.为了访问会话，我在各处使用 IHttpContextAccessor .

I have a page which requests multiple requests concurrently. So those requests are in the very same session. For accessing the session I use everywhere IHttpContextAccessor.

我的问题是，无论何时，某些请求都不会看到其他已设置会话状态的请求，而是会看到某些先前的状态.(再次计时，设置状态操作已经发生，仍然如此)

My problem is that regardless of the timing, some request does not see other requests already set session state, instead sees some previous state. (again in timing, the set state operation happened already, still)

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

As far as I know each requests has its own copy of the state, which is written back... (well "when"?) to the common "one" state. If this "when" is the delayed to when request is completely served, then the scenario what I experiencing is easily happen: The 2nd concurrent request within the session got his copy after the 1st request modified the state but before as it was finished completely.

但是，以上所有内容意味着，在会话中并发请求服务的情况下，无法保持会话完整性.第二个未看到第一个已完成的更改，将回写与第一个已完成的过程更改不一致的内容.

However this all above means that in case of concurrent request serving within a session there is no way to maintain session integrity. The 2nd not seeing the already done changes by the 1st, will write back something what is not consistent with the already done 1st process change.

我错过了什么吗?有什么解决方法吗?(当然要花一些钱)

Am I missing something? Is there any workaround? (with some cost of course)

推荐答案

首先，您可能已经知道这一点，但是有一点需要指出，以防万一:会话状态特定于一个客户端.那么，您在这里谈论的是同一个客户端同时抛出多个并发请求，每个请求都涉及相同的会话状态.通常，这似乎是一个不好的设计.如果出于某种实际的应用原因，有来自同一客户端的多个并发请求，那么这些请求应该是幂等的，或者至少不要踩在彼此的脚趾上.如果是由于不耐烦或恶意而导致客户端仅向服务器发送垃圾邮件的情况，那么您的会话状态是否因此而损坏就完全不用担心了.

First, you may know this already, but it bears point out, just in case: session state is specific to one client. What you're talking about here, then, is the same client throwing multiple concurrent requests at the same time, each of which is touching the same piece of session state. That, in general, seems like a bad design. If there's some actual application reason to have multiple concurrent requests from the same client, then what those requests do should be idempotent or at least not step on each others toes. If it's a situation where the client is just spamming the server, either due to impatience or maliciousness, it's really not your concern whether their session state becomes corrupted as a result.

第二，由于上述原因，并发并不是会话的真正问题.我无法想象有没有用例，客户端需要在哪里发送多个同时请求，每个请求都修改相同的会话密钥.如果有，请通过相应地编辑您的问题进行说明.但是，我仍然会以为您可能不应该一开始就在会话中坚持下去.

Second, because of the reasons outline above, concurrency is not really a concern for sessions. There's no use case I can imagine where the client would need to send multiple simultaneous requests that each modify the same session key. If there is, please elucidate by editing your question accordingly. However, I'd still imagine it would be something you likely shouldn't be persisting in the session in the first place.

也就是说，该会话是线程安全的，因为多个同时进行的读/写操作不会引起异常，但是不能保证也不能保证完整性.这在所有并发方案中都是通用的.如果您担心的话，由您(作为开发人员)来确保数据完整性.您可以通过设计并发策略来做到这一点.从锁/信号灯到门禁访问，或者只是补偿带外发生的事情，这可能是什么.例如，使用EF，您可以在数据库表中使用并发令牌，以防止一个请求覆盖另一个请求.每次成功更新都会修改令牌的值，并在进行更新之前对照当前数据库值检查应用程序已知值，以确保自应用程序启动更新以来未对其进行修改.如果存在，则会引发异常，从而使应用程序有机会通过取消更新，获取新数据并对其进行修改，或者只是推送覆盖来捕获和恢复.这是为了阐明如果会话数据的完整性很重要，您将需要采取某种类似的策略.

That said, the session is thread-safe in that multiple simultaneous writes/reads will not cause an exception, but no guarantee is or can be made about integrity. That's universal across all concurrency scenarios. It's on you, as the developer, to ensure data integrity, if that's a concern. You do so, by designing a concurrency strategy. That could be anything from locks/semaphores to gate access or just compensating for things happening out of band. For example, with EF, you can employ concurrency tokens in your database tables to prevent one request overwriting another. The value of the token is modified with each successful update, and the application-known value is checked against the current database value before the update is made, to ensure that it has not been modified since the application initiated the update. If it has, then an exception is thrown to give the application a chance to catch and recover by cancelling the update, getting the fresh data and modifying that, or just pushing through an overwrite. This is to elucidate that you would need to come up with some sort of similar strategy if the integrity of the session data is important.

这篇关于ASP Net Core 3会话(状态)并发性和完整性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！