Действие Rowlock

Подскажите плиз, я правильно понял?
Делается UPDATE MyTable WITH(ROWLOCK) - в транзакции, в другой сессии тоже делается UPDATE WITH(ROWLOCK) но с иным условием. Так вот, если условия у апдейтов не пересекаются, должны оба апдейта выполниться, один не должен ждать завершения другого? Потому что у меня все равно ждут.

скиньте сюда текст всего запроса, вам помогут.
Вообще МS не советует использовать хинты в запросах - оптимизатор сам разберется как сделать правильно, а вам только лишний повод допустить ошибку.

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

-- Слон

Собственно, я это спрашивал в Организация блокировок , только то не моя ветка. \r
Повторюсь.\r
Имею ХП\r

\r CREATE PROCEDURE tovlock AS \r \r update base_tovlock with (rowlock) \r set spid=@@spid \r where tov_id in (select tov_id from #tovlock) \r \r insert into base_tovlock with(rowlock) \r (tov_id,spid) select tov_id,@@spid \r from #tovlock where #tovlock.tov_id not in (select tov_id from base_tovlock) \r \r delete from #tovlock \r

\r
\r
структура таблиц \r
base_tovlock (tov_id char(9) NOT NULL, spid int NOT NULL) \r
#tovlock (tov_id char(9) NOT NULL) \r
\r
\r
Предполагалось следующее: создается список интересующих товаров в #tovlock, вызывается ХП которая блокирует те tov_id и только те tov_id , которые есть в #tovlock. Соответственно если интересуемые товары уже заблокированы, процедура подождет их "освобождения". Однако в реальности процедура застревает когда заблокированы ЛЮБЫЕ tov_id, а не только те что в списке. Т.е. впечатление, что невзирая на rowlock блокируется вся таблица.

>AlexQC
Как так не должны ждать ?
Как раз и должны - сервер же захватывает, блокирует строк или строки над которым ты проводишь обновление. Соответственно, воторой апдейт и ждет пока первый запрос освободит ресурс.
Да и тем более Сиквел сам выберет какой тип блокировки ему использовать на данный момент. Так что лучше подсказки для блокировок оставь для селекта.
Да кстати, не "всякая" процедура бедт ждать пока ты освободишь ресур, а прост напросто рухнет по тайм-ауту.

to Слон
Индексов у таблицы нет.
И вообще, если все равно блокируется вся таблица, какой смысл в rowlock? Зачем его тогда сделали?

to Белов Владимир
Те которые апдейчу - да. Мне и надо чтобы второй апдейт ждал первого. Но только если их строки пересекаются! А блокируются и те строки, которые под апдейт не попадают (вернее, похоже вся таблица блокируется)!

Таймаут - это уже другая вещь, прямого отношения к вопросу не имеющая.

Судя по коду, ждут у тебя не апдейты, а селекты.

Ты имеешь в виду (select tov_id from base_tovlock)? я и с select tov_id from base_tovlock(nolock) тоже пробовал, результат такой же. Да и если по профайлеру смотреть, оно на апдейте останавливается (или профайлер чего-то недопоказывает). А (select tov_id from #tovlock) на сколько я понимаю тормозится не должен.

Посмотрите здесь: http://www.sql.ru/articles/mssql/TSQL.zip
Слайд называется "Индексы и блокировки".

В том то и дело, что у тебя индексов нет. ROWLOCK только при наличии индексов работает да и то не всегда...
Все равно может быть эскалация блокировки если запрос сложный, но это не твой случай. Построй грамотно индексы и выкини все хинты из запросов, оптимизатор сам разберется, и скорее всего в твоем случае наложит rowlock.