Les informations de contexte n'ont pas de portée (au sens de la portée des variables de langage) et sont liées à la durée de vie de la session. Une fois définies, les informations de contexte restent à la valeur définie jusqu'à ce que la connexion soit fermée (la session se termine) ou jusqu'à ce qu'une nouvelle valeur soit définie. Puisque l'exécution sur une session est toujours séquentiel, il n'est pas question de concurrence.
SI vous définissez les informations de contexte dans une procédure, tout déclencheur exécuté ultérieurement sur cette session verra la valeur des informations de contexte nouvellement définies. Définir la valeur de l'identifiant de l'utilisateur dans les informations contextuelles, comme vous le proposez, et l'utiliser dans les déclencheurs est l'exemple typique de l'utilisation des informations contextuelles et est parfaitement sûr en ce qui concerne la simultanéité, car il n'y a fondamentalement pas de simultanéité à proprement parler. Si vous envisagez de définir les informations de contexte dans une procédure stockée, puis de vous y fier dans un déclencheur qui s'exécute en raison de suppressions qui se produisent dans ladite procédure, votre lot n'est pas encore terminé, donc, selon l'article que vous avez lié, vous récupérez les informations conetxt de sys.dm_exec_requests DMV ou depuis le CONTEXT_INFO() fonction. Il ne sera pas encore poussé dans sys.dm_exec_sessions , cela ne peut se produire qu'après avoir quitté la procédure stockée et terminé tout autre appel dans le lot T-SQL envoyé au serveur (la "requête").
