Problème avec la méthode de rappel et maintien de CultureInfo et ASP.Net HttpRuntime

Voici mon problème. Je travaille sur une solution de commerce électronique qui est déployée dans plusieurs pays européens. Nous persistons toutes les exceptions dans l'application à SQL Server et j'ai trouvé qu'il y a des enregistrements dans le DB qui ont un DateTime dans le futur!Problème avec la méthode de rappel et maintien de CultureInfo et ASP.Net HttpRuntime

Nous définissons la culture dans le fichier web.config, par exemple pt-PT, et le format attendu est JJ-MM-AAAA. Après le débogage, j'ai trouvé le problème avec ces enregistrements 'futurs' dans la base de données à cause des méthodes de rappel que nous utilisons. Par exemple, dans notre architecture Caching nous utilisons Callbacks, en tant que tel -

CacheItemRemovedCallback ReloadCallBack = new CacheItemRemovedCallback(OnRefreshRequest);

Quand je vérifie les fils actuels CultureInfo, sur ces Callbacks il est en États-Unis au lieu de pt-PT et aussi la HttpContext est nulle. Si une exception se produit sur le rappel, notre gestionnaire d'exceptions le signale comme MM-JJ-AAAA et ainsi il est incorrectement conservé à SQL Server.

Malheureusement, dans le code du gestionnaire d'exception, nous utilisons DateTime.Now, ce qui est correct s'il ne s'agit pas d'un rappel. Je ne peux pas modifier ce code pour qu'il soit spécifique à une culture car il est partagé entre d'autres secteurs. Alors, pourquoi les rappels dans ASP.Net ne sont-ils pas maintenus en contexte? Est-il possible de le maintenir sur ce thread de rappel? Quelles sont les meilleures pratiques ici?

Merci.

Source

2009-07-01 Little Larry Sellers

DateTime.Now ne dépend pas de la culture. L'enregistrez-vous en tant que chaîne? ToString est-ce que dépend de la culture.

En fait, en règle générale, essayez de stocker des éléments dans la base de données d'une manière qui ne dépende pas de la culture. Ceci est particulièrement important dans une application Web, où la culture pour chaque demande peut être différente de la suivante. Pour pouvoir "comparer des pommes à des pommes", vous devez ignorer la culture.

Source

2009-07-01 17:02:29

Oui c'est ToString. Je suis d'accord que la culture devrait être ignorée pour stocker dans la base de données, mais c'est un code hérité que je dois traiter. Le problème est dû au fait que le rappel perd le contexte ASP.Net et la culture d'application. C'est ce que je veux essayer de résoudre en quelque sorte. –

Je ne sais pas si ce rappel se produit dans le contexte de la même requête. Si c'est le cas, vous pouvez stocker la culture dans HttpContext.Current.Items ["CultureForRequest"] et la retirer dans le rappel. –

Vous devez séparer le DateTime (recommandé par l'UTC) du reste de la description de l'erreur dans votre gestion de journalisation ET également stocker la culture associée à l'entrée du journal. Ensuite, vous pouvez réassembler l'information avec ces 3 pièces indépendamment.

Le rappel de cache se fait sur un thread threadpool qui dans votre cas a toujours en-US et il n'y a pas de HttpContext. Vous devriez être en mesure de récupérer la culture en associant l'élément de cache supprimé à votre logique de rappel.

Source

2009-07-28 22:32:45 user134706

Problème avec la méthode de rappel et maintien de CultureInfo et ASP.Net HttpRuntime

Répondre

Questions connexes