私はクラウドベースのプロジェクト全体にasyncを実装しています。EFとAsync - 奇妙なライブシナリオ
私は現在、なぜTransactionScopeがランダムにクラッシュするのかを理解しようとしています。 「保留中の操作があるためこの操作を実行できません」または「操作がトランザクションの状態に対して有効ではありません」というメッセージが表示されます。
私はあなたが操作を再試行した場合、それは最終的に動作しますので、それは、ランダムにクラッシュすると言う...
は、最初に私がTransactionScopeAsyncFlowOption.Enabledオーバーロードを実装し...失敗率が減少しました。
その後、私は操作全体に同じDbContextを使用させました（以前のユーザーは、ユーザーの新しいコンテキストを選択するような、CRUD操作ごとに新しいCRUD操作を作成しました）。コンテクスト！新しいセールを作成しますか？この新しいコンテクストでこれをやりましょう...など）。フェイル率はさらに低下した。
それから、できるだけ早くawaitに決めました（以前は、操作の開始時にいくつかのクエリを実行していましたが、結果を使用する前にただ待機していました）。これにより、故障率が大幅に向上しました。
今、FKの不一致を通知するメッセージがログに記録されています...これは非常に堅実なアプリケーションでFKのロジックが間違っているため非常に奇妙なことは非常に基本的な間違いです。ログを見ると、 "クライアントのエラーCLIENT_Aのようなメッセージが表示されます。完了メッセージ：（bla bla bla）データベースで競合が発生しましたdb_CLIENT_B" !!!私のマルチテナントアプリで
、各テナントは、それが自身のデータベースです持っているので、CLIENT_Aはdb_CLIENT_Aに問題があるはずです。私たちはこれについて非常に細心の注意を払っています。
これは本当に深刻な問題です。これは、ユニティコンテナがDbContextの間違ったインスタンスを提供していることを意味します（要求ごとに1つのインスタンスに設定されています）。あるいは、非同期/待機と並行した別個のオペレーションに関して重大な問題が発生しています。 DbContextはスレッドセーフではなく、どちらもResolveですが、一度だけ呼び出されています（DBContextの解決はパイプライン上で非常にすぐに行われます）。
私の質問は何ですか？
PS：最後の7日間に、私はこのために5つのログを持っています。これはもっと頻繁に起こるかもしれませんが（交換）、他のデータベースに互換性のあるFKがある場合は...マネージャーが財務報告を出すのを数日後にします。