Kontextinformationen haben keinen Geltungsbereich (im Sinne des Geltungsbereichs von Sprachvariablen) und sind an die Sitzungslebensdauer gebunden. Einmal eingestellt, bleiben die Kontextinformationen auf dem eingestellten Wert, bis die Verbindung geschlossen wird (die Sitzung endet) oder bis ein neuer Wert eingestellt wird. Da die Ausführung in einer Sitzung immer ist sequentiell, von Parallelität kann keine Rede sein.
Wenn Sie die Kontextinformationen in einer Prozedur festlegen, sieht jeder Trigger, der anschließend in dieser Sitzung ausgeführt wird, den neu festgelegten Wert der Kontextinformationen. Das Festlegen des Benutzer-ID-Werts in den Kontextinformationen, wie Sie vorschlagen, und die Verwendung in Triggern ist das typische Beispiel für die Verwendung von Kontextinformationen und ist in Bezug auf Parallelität absolut sicher, da es im Grunde keine nennenswerte Parallelität gibt. Wenn Sie vorhaben, die Kontextinformationen in einer gespeicherten Prozedur festzulegen und sich dann in einem Trigger darauf verlassen, der aufgrund von Löschvorgängen in der genannten Prozedur ausgeführt wird, wurde Ihr Stapel noch nicht abgeschlossen, sodass Sie ihn gemäß dem von Ihnen verlinkten Artikel abrufen die conetxt-Informationen aus sys.dm_exec_requests DMV oder aus CONTEXT_INFO() Funktion. Es wird noch nicht in sys.dm_exec_sessions gepusht , das kann nur passieren, nachdem Sie die gespeicherte Prozedur verlassen und alle anderen Aufrufe im T-SQL-Batch beendet haben, der an den Server gesendet wird (die „Anfrage“).
