J'ai une DLL CLR (code source écrit en C#) qui est chargée dans SQL Server. Le processus d'initialisation est cher donc c'est quelque chose que je ne veux habituellement faire qu'une seule fois. Cependant, il peut parfois être nécessaire d'initialiser à nouveau et je ne veux pas avoir à redémarrer SQL Server pour le faire. En tant que tel, j'ai pas marqué ces variables statiques en lecture seule. Mon problème est que mes variables statiques sont réinitialisées à null d'une manière apparemment aléatoire. Je suis assez confiant que je n'ai aucun problème de threading et aucun de mes codes ne définit ces valeurs à null de toute façon. En analysant mes fichiers journaux, je peux seulement deviner que SQL Server est en quelque sorte en train de réinitialiser les valeurs à null (peut-être recharger la DLL à certains moments?). Est-ce que SQL Server le fait? Si oui, y a-t-il un moyen de ne pas le configurer?Variables statiques SQL Server CLR redéfinies sur null
Répondre
SQL Server charge et décharge les modules CLR comme bon lui semble (sous la pression de la mémoire, dans le cas d'une exception non gérée, more on it here). Même si vous étiez en mesure de comprendre toutes les conditions et les timings, c'est quelque chose qui va probablement changer dans les versions futures.
La conservation de plus grandes quantités de données ne sera pas bien échelonnée. Écrivez un service Windows pour cela, et appelez-le depuis votre UDF géré via tcp (par exemple). Si vous avez vraiment besoin d'un état in-process, utilisez un mécanisme de cache persistant au lieu de variables statiques (la base de données, le système de fichiers) - ou anticipez que la statique peut être nulle à tout moment, il n'y a rien de mal avec cette approche en soi, à part le problème d'évolutivité, et la simultanéité/synchronisation.
La description est presque le contraire de ce que devrait être une fonction ou un agrégat SQLCLR. Une classe SQLCLR s'exécute dans l'espace mémoire de SQL Server, à l'aide du threading de SQL Server. Son cycle de vie est contrôlé par SQL Server. Par conséquent, il ne devrait pas * effectuer une initialisation coûteuse, ni l'exiger. Il * ne devrait pas * avoir de variables statiques du tout. Il * ne devrait pas * gaspiller la mémoire qui pourrait être utilisée pour mettre les données en cache. En d'autres termes, vous avez des problèmes de threading, mais ceux-ci sont probablement les moindres de vos problèmes. –
Où est le code et qu'essaie-t-il de faire? Pourquoi un assembly SQLCLR nécessite-t-il un type d'initialisation? Il est impossible d'aider sans le code, à part noter que les classes SQLCLR ne sont pas censées fonctionner de cette façon –
Ce code tend la main au gestionnaire de clés pour exporter les clés cryptographiques. Je cache les clés dans la mémoire afin de ne pas avoir à tendre la main au gestionnaire de clés à plusieurs reprises (car c'est le processus coûteux). Malheureusement, je ne suis pas autorisé à poster du code de ce projet particulier. – Hmmmmm