Цитата:
Сообщение от
fed
А ты можешь привести какую-то ссылочку в подтверждение ?
Ну то есть - да - я понимаю что мы не можем заблокировать записи до того момента пока мы их не нашли и не прочитали. Но разве там система не вешает intent locks на более верхнем уровне до момента чтения ?
Вешает, но таблицу накладывается блокировка намерения на эксклюзивный доступ
Простым блокировкам обновления это не препятствует
Блокировка намерения обновления страниц вешается же при фетче - но она, опять же, не мешает блокировке строк
Цитата:
Сообщение от
fed
Кроме того - как-то мне казалось что как раз при работе с серверными курсорами, система фетчит выборку, потом засовывает во временную таблицу в tempdb и потом по ней навигирует (естественно - заблокировав все скопированные записи в исходной таблице).
Нет, такого не встречал - выборка и фетч данных идет напрямую с таблиц, без перекачки куда-то еще (речь не идет о сложных запросах, результаты которых как раз и формируются в tempdb)
Что бы убедиться, можно сделать простой тест - запустить нижеприведенный код в разных сессиях одновременно, без прерывания паузы (во второй сессии сортировка в выборке должна быть в обратном порядке)
X++:
InventTable inventTable;
;
ttsbegin;
select pessimisticLock inventTable
order by itemId;
//order by itemId desc; - для запуска во второй сессии
pause;
ttsabort;Если записей в таблице достаточно, то в результате оба запроса вернут результат
Если же оба запроса будут запущены с одинаковой сортировкой, то один из запросов будет ожидать снятия блокировки ранее запущенным