Issue with Callback method and maintaining CultureInfo and ASP.Net HttpRuntime

Question

Hi All,

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.

Answer 1

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.

Answer 2

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.