Я не думаю, что поведение SQL Server по умолчанию является именно «пессимистическим контролем параллелизма».Давайте рассмотрим следующий простой пример, который работает с уровнем изоляции по умолчанию, READ COMMITTED:
-- Connection one
BEGIN TRANSACTION;
SELECT * FROM Schedule
WHERE ScheduledTime BETWEEN '20110624 06:30:00'
AND '20110624 11:30' ;
-- Connection two
UPDATE Schedule
SET Priority = 'High'
WHERE ScheduledTime ='20110624 08:45:00'
-- nothing prevent this update from completing,
-- so this is not exactly pessimistic
-- Connection one
DELETE FROM Schedule
WHERE ScheduledTime ='20110624 08:45:00' ;
COMMIT ;
-- nothing prevents us from deleting
-- the modified row
Относительно следующего утверждения по ссылке, опубликованной gbn: «Исторически модель управления параллелизмом в SQL Server наУровень сервера был пессимистичным и основан на блокировке. ", я понимаю, что это значит: до 2005 года были предоставлены только инструменты для реализации пессимистического параллелизма.Однако нам все еще нужно было повысить уровень изоляции для достижения пессимистического параллелизма, это не происходило и не происходит по умолчанию.
Я, конечно, могу ошибаться.Я послал Калену Делани, автору этой статьи MSDN, ссылку на эту ветку.Надеюсь, она найдет несколько минут для комментариев.
Редактировать: вот определение MSDN: «Пессимистический контроль параллелизма блокирует ресурсы по мере необходимости на время транзакции. Если не происходит взаимоблокировок, транзакция гарантируется успешное завершение».Очевидно, что по умолчанию этого не происходит, как я показал в моем примере - общая блокировка снимается после прочтения строки.