Каков объем CONTEXT_INFO в SQL Server?
Я использую CONTEXT_INFO для передачи имени пользователя удалить триггеру в целях аудита/таблицы истории. Я пытаюсь понять объем CONTEXT_INFO и если я создаю потенциальное состояние состязания.
Каждая из моих таблиц базы данных имеет сохраненный proc для обработки, удаляет. Удаление сохраненного proc берет идентификатор пользователя в качестве параметра и устанавливает CONTEXT_INFO на идентификатор пользователя. Мой удалять триггер затем захватывает CONTEXT_INFO и использование, что для обновления контрольной таблицы, которая указывает, кто удалил строку (строки).
Вопрос, если два удаляет sprocs от различных пользователей, выполняются одновременно, CONTEXT_INFO может установить в одном из sprocs быть использованным триггером, запущенным другим sproc?
Я видел эту статью http://msdn.microsoft.com/en-us/library/ms189252.aspx, но я не ясен на объеме сессий и пакетов в SQL Server, который является ключевым для статьи, являющейся полезным!
Я отправил бы код, но короткий вовремя в данный момент. Я отредактирую позже, если это не будет достаточно ясно.
Заранее спасибо за любую справку.
2 ответа
Информация контекста не имеет области действия (в смысле области действия языковых переменных) и привязана к времени существования сеанса. После установки контекстная информация остается на установленном значении до тех пор, пока соединение не будет закрыто (сеанс завершится) или пока не будет установлено новое значение. Поскольку выполнение в сеансе всегда последовательно, вопрос о параллелизме не возникает.
ЕСЛИ вы устанавливаете контекстную информацию в процедуре, любой триггер, выполняемый впоследствии в этом сеансе, увидит новое заданное значение контекстной информации. Установка значения идентификатора пользователя в контекстной информации, как вы предлагаете, и использование его в триггерах - это типичный пример использования контекстной информации, который совершенно безопасен в отношении параллелизма, поскольку в основном нет параллелизма, о котором можно было бы говорить. Если вы планируете установить контекстную информацию в хранимой процедуре, а затем полагаться на нее в триггере, который запускается из-за удалений, которые происходят в указанной процедуре, то ваш пакет еще не завершен, поэтому, согласно статье, которую вы связали, вы получаете информация conetxt из DMV sys.dm_exec_requests или из функции CONTEXT_INFO () . Он еще не будет помещен в sys.dm_exec_sessions , что может произойти только после выхода из хранимой процедуры и завершения любого другого вызова в пакете T-SQL, отправленном на сервер («запрос»).
Я использовал именно этот метод для аудита на сайте одного клиента, и они активно используют его уже около 6 месяцев без каких-либо проблем.
Информация о контексте привязана к текущему соединению для текущей партии и любых партий, которые начинаются после завершения текущей партии. Два пользователя в вашей среде либо не будут находиться на одном и том же соединении, либо, если есть совместное использование соединения, они все равно будут иметь свои собственные значения, если они вообще пересекаются. Если один пришел после другого, то второй перезапишет первый, но к тому времени он все равно уже будет завершен. По крайней мере, это мое понимание того, как это работает. Более подробную информацию об этом можно найти в MARS (Multiple Active Result Sets).