qa で使用した後、次のエラーが発生します。
Execution of the command requires an open and available connection. The connection's current state is broken.
EntityFramework のシングルトン インスタンスを使用しています
SOF は次のことを提案します。
サーバーがダウンしているために発生した無効な操作の例外からの EF の回復
1) たまに ContectObject の新しいインスタンスを作成する
2) プール接続数をより多く設定する
これを解決するためのベストプラクティスは何ですか?
Dal操作ごとに新しいcontectObjectを作成するのはもったいないと思います
Dal操作ごとに新しいcontectObjectを作成するのは無駄だと思います
これについて何か証拠はありますか？Entity Frameworkと実際にほとんどのデータアクセスフレームワークは、多くの短命で独立したコンテキスト向けに設計されていると思います。ここで独自のプーリング/キャッシングを実装することは通常アンチパターンであり、結果が古くなり、同時実行性の問題が発生し、障害回復が不十分になる可能性があります（ここの場合のように）。
どのような特定のリソースが無駄になると思いますか？これを実験的に検証しましたか？
基本的に、作業単位ごとに新しいコンテキストを作成することをお勧めします（大まかに要求に対応する可能性があります）-パフォーマンスの違いを測定し、問題が解消されるかどうかを確認します（予想どおり）。テストの一環として、データベースサーバーをネットワークから切断して、実際に回復できることも確認してください...
接続プールについてお読みください。
EFコンテキストを破棄する場合は、基盤となるストアプロバイダー接続を破棄します。ただし、ストア接続を破棄する場合、接続プールを明示的にオフにしていない限り、デフォルトではトランスポートレベルの接続を閉じていません 。
さらに、EFはアプリケーションドメインごとにメタデータビューをキャッシュします。
したがって、EFコンテキストの作成は本当に安価です。
また、すべてのコンテキストインスタンスに変更トラッカーがあることに注意してください。単一のコンテキストがある場合、その変更トラッカーは、具体化された、またはコンテキストに関連付けられたすべてのものを追跡します。「すべてを追跡する」とは、コンテキストを通じて取得したすべてのエンティティインスタンスが破棄されないことを意味します。つまり、トラッカーはそのインスタンスへの参照を保持します。
長寿命のコンテキストインスタンスを作成しないでください。