Проблема с методом обратного вызова и поддержанием CultureInfo и ASP.Net HttpRuntime
Вот моя проблема. Я работаю над решением для электронной коммерции, которое развернуто в нескольких европейских странах. Мы сохраняем все исключения в приложении к SQL Server, и я обнаружил, что в БД есть записи, у которых есть DateTime в будущем!
Мы определяем культуру в файле web.config, например, pt-PT, и ожидаемый формат - DD-MM-YYYY.
После отладки я обнаружил, что проблема с этими "будущими" записями в БД связана с методами обратного вызова, которые мы используем. Например, в нашей архитектуре кэширования мы используем обратные вызовы как таковые -
CacheItemRemovedCallback ReloadCallBack = new CacheItemRemovedCallback(OnRefreshRequest);
Когда я проверяю текущие потоки CultureInfo, для этих обратных вызовов это en-US вместо pt-PT, а также HttpContext имеет значение null. Если исключение возникает в обратном вызове, наш диспетчер исключений сообщает об этом как MM-DD-YYYY, и поэтому оно сохраняется в SQL Server неправильно.
К сожалению, в коде менеджера исключений мы используем DateTime.Now, что хорошо, если это не обратный вызов. Я не могу изменить этот код, чтобы он соответствовал конкретной культуре, потому что он используется совместно с другими вертикалями.
Итак, почему обратные вызовы в ASP.Net не поддерживают контекст? Есть ли способ сохранить его в этой теме обратного вызова? Каковы лучшие практики здесь?
Благодарю.
2 ответа
Вы должны отделить DateTime (рекомендуется UTC) от остальной части описания ошибки в вашем управлении журналами И также сохранить культуру, связанную с записью журнала. Затем вы можете самостоятельно собрать информацию с этими 3 частями.
Обратный вызов кэша поступает в поток пула потоков, который в вашем случае всегда имеет en-US и HttpContext отсутствует. Вы должны быть в состоянии получить культуру, связав удаленный элемент кэша с логикой обратного вызова.
DateTime.Now не зависит от культуры. Вы сохраняете это как строку? ToString зависит от культуры.
Фактически, как правило, старайтесь хранить вещи в базе данных способом, не зависящим от культуры. Это особенно важно в веб-приложении, где культура для каждого запроса может отличаться от следующей. Чтобы иметь возможность "сравнить яблоки с яблоками", нужно игнорировать культуру.