RSS スレッドを読み込んで実行し、結果をデータベースに保存する「ロボット」のバッチがあり、多くのフィードを一度に取得できるように並列化しました。
Parallel.ForEach(context.Feeds, feed => ProcessRssFeed(feed, context));
context.SubmitChanges();
「ProcessRssFeed」関数は、レコードが見つかったときにコンテキストに挿入できます。各フィードは、ゼロから数百のアイテムのいずれかになります。フィードはたくさんあるので、フィードごとに LINQ DataContext を作成したくありませんでした。
ただし、クライアントに何千ものレコードを蓄積する可能性があるのではないかと心配しています。メモリが不足する可能性があると思います。
ここでは同時実行の問題がないため、可能であれば DataContext に「必要に応じて定期的にレコードを送信してください」と伝えたいと思います。これを達成するための実用的な方法はありますか？
それぞれに新しいDataContextものを作成することをお勧めします。DataContextは、実際のデータベース接続に比べて非常に軽量です。データベースに接続するときに接続プールを使用します。個別のDataContextDataContextを使用しても、オーバーヘッドはそれほど大きくありません。
アトミックに送信する必要があるものだけをDataContextに保持し、それを送信して、次のアイテム用に新しいDataContextを作成します。
定期的に送信するための組み込みの方法はありませんが、アイテムの数を監視し、DataContext.GetChangeSet()その数が特定のしきい値を超えたときに送信することができます。ただし、プロファイリングにより、新しいDataContextの作成が実際にシステムのボトルネックであることが示された場合にのみ、これを行う必要があります。
かなりの量のデータを持つオブジェクトが多数ある場合、メモリ使用量を大量に消費し始める可能性があります。SubmitChanges を呼び出すまで、DataContext は追跡されたすべての変更をメモリに保存します。プログラムのメモリ使用量を測定して、これが問題になるかどうかを確認することをお勧めします。メモリが問題である場合は、はい、SubmitChanges を呼び出して、DataContext がその情報の一部をそこからフラッシュできるようにする必要があります。
ただし、単一の呼び出しで SubmitChanges を呼び出すことには、利点と欠点があります。本当に大量のデータがあり、単一の SubmitChanges 呼び出しを使用しているとしましょう。これは、終了するまで、それがオンになっているスレッドでブロックされます。場合によっては、非常に長い時間になる可能性があります。スレッドを再開させたり、進行状況を報告したり、その他の副次的なアクションを実行したい場合、これは良くありません。このような場合、SubmitChanges を定期的に呼び出す必要があります。これにより、スレッドに他のロジックがある場合、または必要な場合に処理を再開させることができます。
どれくらいの時間がかかるかを本当に気にしない場合は、他に何の影響もありません。SubmitChanges を 1 回呼び出すだけで問題ありません。
どちらの場合でも、SubmitChanges は各変更を個別のコマンドに分割し、各コマンドを個別に実行します。そのため、一括またはバッチ コマンドを実行することはなく、SubmitChanges を定期的に呼び出すか、単一の呼び出しを行うかに関係なく、常に 1 つずつ実行されます。
これに関するMSDN ページは、SubmitChanges をもう少しよく理解するのに役立ちます。他にも便利なリソースが散らばっています。