Problem mit Callback-Methode und Pflege von CultureInfo und ASP.Net HttpRuntime

Question

Hier ist mein Problem. Ich arbeite an einer E-Commerce-Lösung, die in mehreren europäischen Ländern eingesetzt wird. Wir behalten alle Ausnahmen innerhalb der Anwendung zu SQL Server bei und ich habe gefunden, dass es Datensätze in der DB gibt, die eine DateTime in der Zukunft haben!

Wir definieren die Kultur in der web.config, zum Beispiel pt-PT, und das erwartete Format ist DD-MM-YYYY.

Nach dem Debugging habe ich festgestellt, dass das Problem mit diesen 'zukünftigen' Datensätzen in der Datenbank wegen der von uns verwendeten Rückrufmethoden liegt. Zum Beispiel in unserer Caching-Architektur verwenden wir Rückrufe, wie zum Beispiel -

CacheItemRemovedCallback ReloadCallBack = new CacheItemRemovedCallback(OnRefreshRequest); 

Wenn ich die aktuellen Themen Culture überprüfen, auf diesen Rückrufen sind es en-US statt pt-PT und auch die Httpcontext ist Null. Wenn eine Ausnahmebedingung auf dem Rückruf auftritt, meldet unser Ausnahmemanager sie als MM-TT-JJJJ und wird daher falsch auf SQL Server gespeichert.

Leider verwenden wir im Code des Ausnahme-Managers DateTime.Now, was in Ordnung ist, wenn es kein Rückruf ist. Ich kann diesen Code nicht ändern, um kulturspezifisch zu sein, da er über andere Branchen hinweg geteilt wird.

Also, warum Callbacks in ASP.Net Kontext nicht beibehalten? Gibt es eine Möglichkeit, es auf diesem Rückruf-Thread zu verwalten? Was sind die besten Praktiken hier?

Danke.

Answer 1

DateTime.Now hängt nicht von der Kultur ab. Speichern Sie es als String? ToString ist abhängig von Kultur.

In der Regel versuchen Sie in der Regel, Dinge in der Datenbank in einer Weise zu speichern, die nicht von Kultur abhängig ist. Dies ist besonders wichtig in einer Web-Anwendung, wo die Kultur für jede Anfrage von der nächsten abweichen kann. Um Äpfel mit Äpfeln vergleichen zu können, muss man Kultur ignorieren.

Answer 2

Sie sollten die DateTime (UTC empfohlen) vom Rest der Fehlerbeschreibung in Ihrem Logging-Management trennen UND auch die mit dem Log-Eintrag verknüpfte Kultur speichern. Dann können Sie die Informationen mit diesen 3 Stücken unabhängig zusammenbauen.

Der Cache-Callback kommt auf einen Threadpool-Thread, der in Ihrem Fall immer en-US hat und es gibt keinen HttpContext. Sie sollten in der Lage sein, die Kultur abzurufen, indem Sie das entfernte Cache-Element mit Ihrer Callback-Logik verknüpfen.