установить CONTEXT_INFO выбрать context_info (), блокировка - PullRequest
1 голос
/ 08 января 2010

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

В момент времени T0: SPID 1: начать транзакцию ... вставить в T (...) значения (...); ... совершить;

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

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

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

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

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

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

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

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

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

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

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

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

С уважением, Йенс Норденбро


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

1 Ответ

1 голос
/ 08 января 2010
  • CONTEXT_INFO для каждого соединения
  • sysprocesses не являются реальной таблицей, и вы не можете использовать подсказку (например, WITH TABLOCKX)

Редактировать, после другого ответа от ОП:

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

Что касается "реальной таблицы" ... это "поддельная таблица" согласно тесту "TableIsFake" ОБЪЕКТ ОБЪЕКТА :

Таблица не настоящая. Он материализуется по требованию ядра СУБД SQL Server.

...