EF和异步-奇怪的实时场景 [英] EF and Async - Weird live scenario

问题描述

我正在整个基于云的项目中实现异步。

I'm implementing async all over my cloud-based project.

我现在试图弄清为什么 TransactionScope 不断崩溃的原因。消息是由于有待处理的操作而无法执行此操作或该操作对于事务状态无效，其他类似。

我说它随机崩溃，因为如果重试

I'm now trying to figure out why my TransactionScope keeps crashing randomly. The messages are "Cannot perform this operation because there are pending operations" or "The operation is not valid for the state of the transaction" an other similar.
I say that it crashes randomly, because if you retry the operation, it works eventually...

首先，我实现了 TransactionScopeAsyncFlowOption.Enabled 重载...失败率降低。

然后，我使整个操作使用相同的 DbContext （以前的家伙为每个CRUD操作创建了一个新操作，例如选择一个用户？为您提供新的上下文！现在您想要该用户的销售吗？让我使用新的上下文获得该价格！创建新的销售？让我们在此新上下文中进行此操作，依此类推...）。失败率甚至进一步下降。

然后我决定尽快等待（以前我在操作开始时就发出了一些查询，并且仅在使用结果之前等待）。

At first I implemented the TransactionScopeAsyncFlowOption.Enabled overload... the fail ratio decreased.
Then I made the whole operation use the same DbContext (previous guys created a new one for each CRUD operation, like selecting a user? new context for you! now you want the sales of that user? let me get that using a new context! Create a new sale? Lets do that on this new context here... and so on...). fail ratio declined even further.
Then i decided to await as soon as possible (previously i was firing some queries at the start of the operation, and only waiting right before using the result). That significantly improved the fail ratio.

现在，我在日志中收到一条消息，表明FK不匹配...那真的很奇怪，因为这是一个非常可靠的应用程序， FK逻辑出错是一个非常基本的错误。查看日志，我看到类似客户端 CLIENT_A 的错误。完整的消息：（bla bla bla bla）数据库 db_CLIENT_B 中发生了冲突 ！!!!

Now, I got a message in my logs that signaled a FK mismatch... Thats really weird because this is a very solid app and FK logic going wrong is a very basic mistake. Looking at the log, i see something like "Error for client CLIENT_A. Complete message: (bla bla bla) The conflict occurred in database db_CLIENT_B"!!!

在我的多租户应用程序中，每个租户都有自己的数据库，因此 CLIENT_A 应该只对 db_CLIENT_A 有问题。我们对此非常谨慎。

In my multi-tenant app, each tenant has it's own database, so CLIENT_A should have problems only with db_CLIENT_A. We are very meticulous about this.

那是一个非常严重的问题。这意味着要么统一容器给出了错误的 DbContext 实例（它为每个请求配置了单个实例），要么就异步/等待和并行以及独特的操作...考虑到DbContext不是线程安全的，而且Resolve也不是线程安全的，我认为这可能是混合的，尽管它只被调用一次（针对DBContext的解析在管道上很快发生）

That is a really serious problem. That means that either unity container is giving the wrong instance of DbContext (it's configured for single instance per request) or there's a serious problem going on regarding the async/await and parallel and distinct operations... I think it could be mix, taking into account that DbContext is not thread-safe and neither is the Resolve, although it's getting called only once (resolve for DBContext happens very soon on the pipeline)

所以我的问题是：我该怎么办？

So my question is: What can i do to figure this out?

PS ：在最近7天，我为此有5条日志。这可能会发生更多次（切换），但是如果另一个数据库具有兼容的FK ...那么，我将在几天后经理开始发布财务报告的时候在这里进行说明...

PS: ON the last 7 days, i have 5 logs for this. This might've happen more times (the switching) but if the other database has a compatible FK... well, i will here for that in a couple of days when managers start emitting financial reports...

推荐答案

这是Unity引起的。当我在异步范围内调用解决时，就会发生这种情况。

This is caused by Unity. This happens when I call 'Resolve' within a async scope.

这篇关于EF和异步-奇怪的实时场景的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！