私の.NETMVCプロジェクトは複数のユーザーでテストの段階に達しており、Linq2Sql DataReaderの問題に関連して（サイト内の任意の画面から）一見ランダムなエラーが発生しています
。および
'ExecuteReaderには、開いていて利用可能な接続が必要です。接続の現在の状態は閉じられています。
これらのエラーは、リンクがダブルクリックされた場合、ブラウザの複数のタブ、または異なるブラウザが同時に更新された場合のシングルユーザーテスト中にも頻繁に表示されません。
これらの問題がDataContextのスレッド化の問題にあるのではないかと思います。
現在、私はビジネスプロセスごとに個別のリポジトリを使用するリポジトリアプローチを使用しています。各リポジトリクラスは、そのコンストラクタでDataContextインスタンスを起動し、これはリポジトリ内のほとんどのメソッドで使用されます。
ただし、一部のメソッドはDataLoadOptionsを更新して、ビューデータの積極的な読み込みを強制するため、これらのメソッドはDataContextの独自のインスタンスを作成します。
また、一部の画面には複数のビジネスオブジェクトからの情報が表示されるため、1つのリクエストに2つまたは3つのリポジトリが含まれる場合があります。その結果、リクエストごとに多数の個別のDataContextインスタンスが作成される可能性があります。
必要に応じてDataLoadOptionsを使用し、クエリ結果にToList（）を適用して、すべてが事前に読み込まれるようにする（ビューがレンダリングされるまで待機しない）ようにすることで、積極的な読み込みアプローチを適用しようとしました。したがって、各DataContextはかなり短い期間。
エラーは同じDataContextを再利用する複数のスレッドに関連しているように見えるので、Rick Strahlのスレッド固有のDataContextFactory（http://www.west-wind.com ）に沿って、リクエストごとに1つのDataContextを実装することを考えています。 /weblog/posts/246222.aspx ）またはSteve Sandersonの例（ http://blog.stevensanderson.com/2007/11/29/linq-to-sql-the-multi）のような単純な「作業単位データストア」アプローチ-tier-story /）。
しかし、解決すべきDataLoadOptionsの問題があります。追加のスレッド固有のDataContextを作成することもできますが、それは、リクエストごとに1つのDataContextを使用するという私の目標からは外れているようです。したがって、同じDataContextを再利用するが、Kevin Watkinの例（ http://www.mrkwatkins.co.uk/Blog/2010/05/）のように一部のメソッドのLoadOptionsを一時的に変更するか
、標準のDataLoadOptionsアプローチを廃止することを検討しています。 Visual Studioマガジン（http://visualstudiomagazine.com/Articles/2007/11/01/Optimize-LINQ-to-SQL-Performance.aspx？ページ=3）
だから私の質問は、誰かが同様のランダムなDataReaderの問題を経験したことがありますか、どのようにそれらを解決しましたか、そして私がリンクしたそれらのソリューションを実装することによって問題を解決する可能性がありますか？
いつものように時間は厳しいので、問題が実際にどこか別の場所にある場合は、ソリューションの実装に費やしたくありません。どんな助けでも大歓迎です！
PS。これは非常に高レベルの質問であり、問題が実際にどこにあるのかわからないため、特定のコード例は含めていません。