Коллеги, что вы думаете о данном коде? 2MikeR

[AndyD]

Цитата:

Сообщение от fed

А ты можешь привести какую-то ссылочку в подтверждение ?

Ну то есть - да - я понимаю что мы не можем заблокировать записи до того момента пока мы их не нашли и не прочитали. Но разве там система не вешает intent locks на более верхнем уровне до момента чтения ?

Вешает, но таблицу накладывается блокировка намерения на эксклюзивный доступ
Простым блокировкам обновления это не препятствует

Блокировка намерения обновления страниц вешается же при фетче - но она, опять же, не мешает блокировке строк

Цитата:

Сообщение от fed

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

Нет, такого не встречал - выборка и фетч данных идет напрямую с таблиц, без перекачки куда-то еще (речь не идет о сложных запросах, результаты которых как раз и формируются в tempdb)


Что бы убедиться, можно сделать простой тест - запустить нижеприведенный код в разных сессиях одновременно, без прерывания паузы (во второй сессии сортировка в выборке должна быть в обратном порядке)

    InventTable inventTable;
    ;
    
    ttsbegin;
    
    select pessimisticLock inventTable
    order by itemId;
    //order by itemId desc; - для запуска во второй сессии
    
    pause;
    ttsabort;

Если записей в таблице достаточно, то в результате оба запроса вернут результат

Если же оба запроса будут запущены с одинаковой сортировкой, то один из запросов будет ожидать снятия блокировки ранее запущенным