ファイルの到着時にイベントを発生させるファイル ウォッチャーを含む Windows サービスがあります。イベントが発生すると、Ninject を使用して、Ninject を介して注入される Entity Framework コンテキストへの参照を持つビジネス レイヤー オブジェクトを作成します。私の Web アプリケーションでは、常にコンテキストに InRequestScope を使用していました。これにより、1 つのリクエスト内で、すべてのビジネス レイヤー オブジェクトが同じ Entity Framework コンテキストで動作します。私の現在の Windows サービス シナリオでは、Entity Framework コンテキスト バインディングを InThreadScope バインディングに切り替えるだけで十分でしょうか?
理論的には、サービス内のイベント ハンドラーがトリガーされると、それは何らかのスレッドで実行されます。別のファイルが同時に到着すると、別のスレッドで実行されます。したがって、両方のイベントが Entity Framework コンテキストを共有することはありません。つまり、Web 上の 2 つの異なる http 要求と同じです。
私を悩ませているのは、Ninject wiki を見ると、これらのスレッドスコープのオブジェクトが破壊されていることです。
.InThreadScope()- タイプの 1 つのインスタンスがスレッドごとに作成されます。
.InRequestScope()- このタイプのインスタンスは Web リクエストごとに 1 つ作成され、リクエストが終了すると破棄されます。
これに基づいて、リクエストが終了したとき（またはその後のある時点）で InRequestScope オブジェクトが破棄される（ガベージコレクション？）ことを理解しています。これは、 InThreadScope オブジェクトがどのように破棄されるかについては何も述べていません。私の例に戻ると、ファイル ウォッチャー イベント ハンドラー メソッドが完了すると、スレッドは離れます (スレッド プールに戻りますか?) 注入された InThreadScope-d オブジェクトはどうなりますか?
編集: InThreadScope() を使用すると、filewatcher のハンドラーが終了したときにオブジェクトが破棄されないことは明らかです。フォルダーに多くのファイルをドロップすることでこれを再現できましたが、最終的に同じスレッド ID を取得したため、以前とまったく同じ Entity Framework コンテキストが得られたため、私のアプリケーションには十分ではありません。この場合、5 分後に到着したファイルは、以前に同じスレッドに割り当てられた古いコンテキストを使用している可能性があります。