набор CONTEXT_INFO выберите context_info(), блокировка

Question

Представьте таблицу T, которая используется следующим образом:

В момент времени Т0: ИСП 1: начать транзакцию ... вставку в Т (...) значения (...); ... commit;

В момент времени T1 SPID 2: начать транзакцию выбрать * из T где C = cval; ... commit;

Предположим, что уровень изоляции транзакции установлен на сериализуемый. Также предположим, что SPID1 удается взять TABLOCKX на T до времени T1, а также что SPID1 выполняет длинную транзакцию, в результате чего SPID2 ожидает, когда TABLOCKX на T будет выпущен.

Теперь рассмотрим тот же сценарий, используя CONTEXT_INFO вместо Т

В момент времени Т0: ИСП 1: начать транзакцию ... SET CONTEXT_INFO = 0xFF; ... конец;

В момент времени T1 SPID 2: начать транзакцию select context_info(); ... конец;

Снова предположим, что уровень изоляции транзакции установлен на сериализуемый.

Я знаю, что CONTEXT_INFO за соединение. Я не предполагаю, что SPID 1 и SPID 2 обмениваются данными с помощью CONTEXT_INFO. Они полностью независимы, предполагают, что они используют CONTEXT_INFO для отдельных целей синхронно.

Теперь выбор выполняется без какого-либо ожидания из-за TABLOCKX. На самом деле я не смог спровоцировать любой тип ожидания из-за блокировки с помощью CONTEXT_INFO.

Это нормально со мной, так как мне нужно это поведение. Моя проблема заключается в том, что хотя CONTEXT_INFO должен быть переменной памяти в sql-сервере в «SPID-represenation», он, похоже, хранится в таблице с именем master.dbo.sysprocesses на MSSQL2000 (select context_info() здесь не будет работать) и в sys.sysprocesses на более поздних выпусках MSSQL Server.

Не эти таблицы действуют как все остальные таблицы в отношении блокировки или являются ли эти таблицы просто окнами переменным, не подчиняющимся тем же правилам, что и другие таблицы?

Еще одна вещь, которая меня поразила, заключается в том, что блокировка типа TAB, IS-mode на spt_values ​​принимается upcon set context_info и KEY-типа, блокировки режима RangeS-S при чтении sysprocesses. Но каковы реальные последствия этого, я не понимаю, поскольку это внутренний объект.

Пожалуйста, просветите меня.

С уважением, Jens Nordenbro

---

• не было достаточно ясно, я знаю CONTEXT_INFO это за соединение. Я не предполагаю, что SPID 1 и SPID 2 обмениваются данными с помощью CONTEXT_INFO. Они полностью независимы, предполагают, что они используют CONTEXT_INFO для отдельных целей.Я просто боюсь, что им нужны одни и те же блокирующие ресурсы. Вот о чем идет речь.
• Что вы подразумеваете под HINT?

Answer 1

• CONTEXT_INFO это за соединение
• sysprocesses не является реальной таблицы, и вы не можете использовать подсказку (например, TABLOCKX)

Edit, после того, как другой ответ О.П.:

sysprocesses не имеет блокировок или разногласий, которые повлияют на ваш код. То есть ваше использование CONTEXT_INFO не будет затронуто тем, что происходит внутри с sysprocesses.

Что касается «реальной таблицы» ... это «подделка стол», как на тест «TableIsFake» из OBJECTPROPERTY:

Таблица не реально. Он материализован внутренне по требованию SQL Server Database Engine.