コールバックメソッドの問題とCultureInfoおよびASP.Netの保守に関する問題HttpRuntime

Question

ここは私の問題です。私は、複数のヨーロッパ諸国に展開されているEコマースソリューションに取り組んでいます。私たちはアプリケーション内のすべての例外をSQL Serverに保持しており、DBには将来のDateTimeを持つレコードがあることがわかりました。

cultureはweb.configで定義します（pt-PTなど）。期待される形式はDD-MM-YYYYです。

デバッグ後、これらの「将来の」レコードの問題は、私たちが使用するコールバックメソッドが原因であることが判明しました。たとえば、私たちのような、コールバックを使用して、当社のキャッシュアーキテクチャに - 私はのCultureInfo現在のスレッドをチェックすると

CacheItemRemovedCallback ReloadCallBack = new CacheItemRemovedCallback(OnRefreshRequest); 

、これらのコールバックにそれがen-USでの代わりに、PT-PTであり、またのHttpContextがnullです。 Callbackで例外が発生した場合、例外マネージャはMM-DD-YYYYとして報告し、SQL Serverに間違って永続化されます。

残念ながら、例外マネージャーコードでは、DateTime.Nowを使用しています。これは、コールバックでない場合は問題ありません。このコードを他の分野で共有されているため、文化固有のものに変更することはできません。

なぜ、ASP.Netへのコールバックはコンテキストを維持しないのですか？このコールバックスレッドでそれを維持する方法はありますか？ここでベストプラクティスは何ですか？

ありがとうございました。

Answer 1

DateTime.Nowは文化に依存しません。それを文字列として保存していますか？ ToString はに依存します。

実際、原則として、文化に依存しない方法でデータベースに物事を保存しようとします。これは、Webアプリケーションでは特に重要です。ここでは、各リクエストのカルチャが次と異なる場合があります。 「リンゴとリンゴを比較する」ためには、カルチャを無視する必要があります。

Answer 2

ロギング管理の残りのエラー記述とDateTime（UTC推奨）を分離し、ログエントリに関連付けられたカルチャも保存する必要があります。その後、これら3つの情報を個別に再構成することができます。

キャッシュコールバックは、あなたのケースでは常にen-USを持ち、HttpContextがないスレッドプールスレッドにあります。削除されたキャッシュ項目をコールバックロジックに関連付けることによって、カルチャを取得できるはずです。