このコードを検討してください...
using System.Threading;
//...
Timer someWork = new Timer(
delegate(object state) {
//Do some work here...
},
null, 0, 60000);
HttpContext.Current.Application["SomeWorkItem"] = someWork;
これは危険でしょうか？サイトの実行中にバックグラウンドでいくつかの作業を実行するためにアプリケーションにタイマーをキャッシュすることは安全に思えますが、これについて経験がある人はいないかと思いました。
バックグラウンドで実行するサービスを作成する方が確かに優れていると確信していますが、それが常にオプションであるとは限りません。これは代替案ですか？
System.Threading.Timer は ASP.Net と同じように、ThreadPool からのスレッドを使用するため、これは一般的に悪い考えです。
何らかの理由でタイマー デリゲートがブロックまたは停止した場合、タイマーはタイムアウト期間後に新しいスレッドを開始するだけで、ASP.net で利用可能なスレッドを消費します。
それらがすべてブロックし始めると、事実上、それ以上 Web 要求を処理できなくなります (おそらく悪いことです)。
これに関する問題は、プロセスがまだ生きていることが保証されていないことです。IIS は基本的に必要に応じてプロセスを再利用するため、実行されないリスクがあります。
この作業を行う必要がある場合は、Web 呼び出しにコーディングするか、サーバーのバックグラウンドでサービスを実行する必要があります。
ワーカー プロセスがリサイクルされたり、AppDomain がクラッシュしてワーク アイテムが強制終了されたりする可能性があるため、これは危険です。
その作業項目をサービスに取り込める場合は、Windows サービスで問題ない可能性があります。作業に HttpContext が必要な場合は、Windows サービスに Web サービスを呼び出して定期的に呼び出しを実行させたい場合がありますが、これは理想的ではありませんが機能する可能性があります。
それは理にかなっていますが、冗談として、サイトが閉鎖された場合に作業を実行する必要がなくなったらどうしますか? Application_Start イベントに関連付けられていて、ユーザーがサイトを閲覧しているときにのみ実行する必要がある場合、その時点でどのようなリスクがありますか?
良い答えです。それが内部でどのように機能するかについて、もう少し興味があります。
サイトでページを実行するスケジュールされたタスクをセットアップすることをお勧めします。私は通常、次のようにスケジュールされたタスクを .vbs ファイルにポイントします。
エラー時再開次へ
Dim objRequest
薄暗い URL
objRequest = CreateObject("Microsoft.XMLHTTP") を設定します。
URL = "http://www.mywebsite.com/cron/pagetorun.ashx"
objRequest.open "POST"、URL、false
objRequest.Send
objRequest = Nothing を設定
Omar Al Zabir は、この目的でのキャッシュ アイテム コールバックの使用に関する優れた投稿をしています。