回调方法和维护 CultureInfo 和 ASP.Net HttpRuntime 的问题
这是我的问题。 我正在开发一个部署到多个欧洲国家的电子商务解决方案。 我们将应用程序中的所有异常持久化到 SQL Server，我发现数据库中存在具有未来日期时间的记录！
我们在 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 回调不维护上下文呢？ 有什么办法可以在这个回调线程上维护它吗？ 这里的最佳实践是什么？
谢谢。
Here is my issue. I am working on an E-commerce solution that is deployed to multiple European countries. We persist all exceptions within the application to SQL Server and I have found that there are records in the DB that have a DateTime in the future!
We define the culture in the web.config, for example pt-PT, and the format expected is DD-MM-YYYY.
After debugging I found the issue with these 'future' records in the DB is because of Callback methods we use. For example, in our Caching architecture we use Callbacks, as such -
CacheItemRemovedCallback ReloadCallBack = new CacheItemRemovedCallback(OnRefreshRequest);
When I check the current threads CultureInfo, on these Callbacks it is en-US instead of pt-PT and also the HttpContext is null. If an exception occurs on the Callback our exception manager reports it as MM-DD-YYYY and thus it is persisted to SQL Server incorrectly.
Unfortunately, in the exception manager code, we use DateTime.Now, which is fine if it is not a callback. I can't change this code to be culture specific due to it being shared across other verticals.
So, why don't callbacks into ASP.Net maintain context? Is there any way to maintain it on this callback thread? What are the best practices here?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
DateTime.Now 不依赖于文化。 您是否将其保存为字符串？ ToString确实取决于文化。
事实上，作为一般规则，尝试以不依赖于文化的方式将内容存储在数据库中。 这在 Web 应用程序中尤其重要，因为每个请求的文化可能与下一个请求不同。 为了能够“比较苹果”，你需要忽略文化。
DateTime.Now does not depend on culture. Are you saving it as a string? ToString does depend on culture.
In fact, as a general rule, try to store things in the database in a manner not dependent on culture. This is especially important in a web application, where the culture for each request may be different from the next. In order to be able to "compare apples to apples", you need to ignore culture.
您应该将日期时间（建议使用 UTC）与日志记录管理中的其余错误描述分开，并存储与日志条目关联的区域性。 然后你可以用这三部分独立地重新组合信息。
缓存回调来自线程池线程，在您的情况下，该线程始终具有 en-US 并且没有 HttpContext。 您应该能够通过将已删除的缓存项与回调逻辑关联来检索区域性。
You should separate the DateTime (UTC recommended) from the rest of the error description in your logging management AND also store the culture associated with the log entry. Then you can reassemble the info with these 3 pieces independently.
The cache callback comes on a threadpool thread which in your case always has en-US and there's no HttpContext. You should be able to retrieve the culture by associating the removed cache item with your callback logic.