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

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

Каждая из моих таблиц базы данных имеет хранимую процедуру для обработки удалений. Сохраненная процедура удаления принимает идентификатор пользователя в качестве параметра и задает для параметра CONTEXT_INFO значение идентификатора пользователя. Затем мой триггер удаления захватывает CONTEXT_INFO и использует его для обновления таблицы аудита, которая указывает, кто удалил строки.

Вопрос в том, если два процесса удаления от разных пользователей выполняются одновременно, может ли CONTEXT_INFO, установленный в одном из процессов, использоваться триггером, запущенным другим процессом?

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

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

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


sql-server stored-procedures sql-server-2008 triggers context-info
person JasonS    schedule 11.06.2010    source источник

Ответы (2)


arrow_upward
33
arrow_downward

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

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

person Remus Rusanu    schedule 12.06.2010

arrow_upward
6
arrow_downward

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

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

person Tom H    schedule 11.06.2010