Какова область действия CONTEXT_INFO в SQL Server?

Я использую CONTEXT_INFO для передачи имени пользователя в триггер delete для целей таблицы аудита/истории. Я пытаюсь понять область действия CONTEXT_INFO, и если я создаю потенциальное состояние гонки.

Каждая из моих таблиц базы данных хранит proc для обработки удалений. Удаленный хранимый процесс принимает userId в качестве параметра и устанавливает CONTEXT_INFO в userId. Мой триггер delete захватывает CONTEXT_INFO и использует его для обновления таблицы аудита, которая указывает, кто удалил строки.

Вопрос заключается в том, что если два раза удаляются sprocs от разных пользователей, может ли CONTEXT_INFO, установленный в одном из sprocs, потреблять триггер, запускаемый другим sproc?

Я видел эту статью http://msdn.microsoft.com/en-us/library/ms189252.aspx, но я не понимаю, сфера охвата сеансов и партий в SQL Server, которая является ключевой чтобы стать полезной!

Я бы опубликовал код, но на данный момент короткий. Я отредактирую позже, если это недостаточно ясно.

Заранее благодарим за помощь.

Ответ 1

Контекстная информация не имеет области видимости (в смысле области переменных языка) и привязана к времени жизни сеанса. После установки контекстная информация остается в значении, установленном до тех пор, пока соединение не будет закрыто (сеанс завершается) или пока не будет установлено новое значение. Поскольку выполнение в сеансе всегда последовательное, вопрос о concurrency не существует.

Если вы установите контекстную информацию в процедуре, любой триггер, впоследствии выполненный на этом сеансе, увидит вновь заданное значение контекстной информации. Установка значения идентификатора пользователя в информации контекста, как вы предлагаете, и его использование в триггерах является типичным примером использования контекстной информации и совершенно безопасна в отношении concurrency, поскольку в принципе нет concurrency, чтобы говорить о, Если вы планируете установить контекстную информацию в хранимой процедуре, а затем полагаться на нее в триггере, который запускается из-за удалений, которые происходят в указанной процедуре, то ваша партия еще не закончилась, в соответствии со статьей, которую вы связали, вы извлекаете информацию о conetxt из sys.dm_exec_requests DMV или из функции CONTEXT_INFO(). Он еще не будет помещен в sys.dm_exec_sessions, что может произойти только после выхода из хранимой процедуры и завершения любого другого вызова в пакете T-SQL, отправленного на сервер ( "запрос" ).

Ответ 2

Я использовал этот точный метод для одитинга на одном клиентском сайте, и они использовали его в течение почти 6 месяцев без проблем.

Контекстная информация привязана к текущему соединению для текущей партии и любых партий, которые начинаются после завершения текущей партии. Два пользователя в вашей среде либо не будут в одном соединении, либо если есть совместное использование, они все равно будут иметь свои собственные значения, если они вообще перекрываются. Если кто-то пришел за другим, то второй переписал бы первый, но в любом случае это было бы сделано с ним. По крайней мере, это мое понимание того, как это работает. Вы можете найти MARS (несколько активных наборов результатов) для получения дополнительной информации об этом.