Мне трудно привести пример, в котором serializable transaction не обеспечивает true serializibility в терминах того документа. SQL сервер блокирует все записи, которые ему приходилось просмотреть, чтобы получить результат - а не только те, которые в результат попали.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
create table tmpUsers(
id int identity( 1 , 1 ),
name varchar( 255 ),
summa int
)
insert into tmpUsers(name,summa) values ('masha', 1 )
insert into tmpUsers(name,summa) values ('sasha', 1 )
begin tran
select summa from tmpUsers (updlock,holdlock,rowlock) where name = 'masha'
sp_lock @@spid
select @@Trancount
Вы увидите, что транзакция получила Exclusive lock на таблицу. Несмотря на rowlock. Понятно, что конкурентная транзакция будет заблокирована, и не сможет вкатать ещё одну строчку с name=masha, и этим нарушить serialazibility.
Это, кстати, эскалации блокировок никак не касается, без разницы - заблокирована таблица или все страницы в ней.
Давайте я с другой стороны подойду, раз уж взялся - В Какой Ситуации Блокировки По Предикатам Могли Бы Повысить Производительность?
Да в этой же. Почему бы серверу не блокировать всю таблицу, а проверять каждый следующий запрос, не касается ли он строчек с name=masha? Тогда бы второй коннект мог апдэйтить where name='sasha' одновременно с нашей транзакцией.
Вы возразите, мол нужно индекс по имени построить, а я отвечу - ну пусть не name=, а name like '%
