Блокировка при чтении?

@kotelok · Регистрация: 08.08.2014

Студворк — интернет-сервис помощи студентам

Есть типовой пример взаимной блокировки ресурса.

T-SQL
1
2
3
4
5
create table smp
(
    smp_id int not null identity(1, 1) primary key,
    some_data varchar(84) not null,
);

T-SQL
1
2
3
4
5
6
7
8
9
10
set transaction isolation level serializable;
begin transaction;
 
select * from smp /*with (tablockx)*/ where smp.some_data = '1234';
 
-- какая-то БЛ, анализ результатов 'select', принятие решения на модификацию/добавление
 
insert into smp (some_data) values ('1234');
 
commit transaction;

1. Первое подключение выполняет 'select', второе подключение тоже выполняет 'select' (который не блокируется, т.к. select накладывает на ресурс блокировку 'shared lock', которая не блокирует чтение).
2. Оба подключения, проанализировав результаты запроса, принимают решение добавить запись в БД.
3. Первый 'insert' упирается в блокировку от второго 'select', второй 'insert' - в блокировку от первого 'select'.
4. Ок, deadlock, sqlserver немного подождёт, сгенерирует соответствующую ошибку для одного из коннектов, закроет его транзакцию, а другой коннект при этом завершится корректно. Данные согласованы, но реализация через deadlock и отлов соответствующего исключения выглядит слишком костыльно.

Вопрос - как это правильно решать без переноса части БЛ в базу и без взаимных блокировок?

Если снизить уровень изоляции, то взаимной блокировки не будет, но и согласованность данных тогда не гарантируется, т.к. 'insert' будет происходить не в том состояние таблицы, в котором она была на момент 'select'.

Блокировать на уровне логики приложения - весьма сложная задача (экземпляров сервера может быть много, база общая).

Вариант, который работает - выборка с эксклюзивной блокировкой таблицы (закомментированный фрагмент 'with (tablockx)'). Но подобное решение вызывает некоторые сомнения, т.к. и упоминается (хотя сценарий вполне типовой) мало где, и в EFCore для этого дефолтного функционала нет.

Вероятно, это можно решить как-то иначе?

@Usaga · 20.07.2022, 13:15

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

Вариант, который работает - выборка с эксклюзивной блокировкой таблицы (закомментированный фрагмент 'with (tablockx)').

Максимально фиговый вариант в большинстве случаев. Гасит конкуретный доступ к данным на корню.

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

но реализация через deadlock и отлов соответствующего исключения выглядит слишком костыльно.

Разве?

@kotelok · 20.07.2022, 13:55 **[ТС]**

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

Максимально фиговый вариант в большинстве случаев. Гасит конкуретный доступ к данным на корню.

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

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

Разве?

На первый взгляд да. Но это, похоже, самый оптимальный вариант - при отлове специфичного deadlock-исключения либо выдать HTTP-500, либо просто тихо повторить попытку (сколько-то раз) и почти наверняка получить успешное завершение.

@Andrey-MSK · 20.07.2022, 14:01

kotelok, А какой шанс того, что одни и те же данные будут редактировать два пользователя одновременно?
Может проще использовать timestamp и при сохранении данных проверять его? Если разные, то вывести пользователю новые данные для сравнения...

@kotelok · 20.07.2022, 14:17 **[ТС]**

Сообщение от Andrey-MSK

А какой шанс того, что одни и те же данные будут редактировать два пользователя одновременно?

Не обязательно одни и те же. Выше сценарий с добавлением записи в таблицу с предварительным сканированием. Там, при serializable-транзакции, select накладывает на таблицу блокировку, которая, пока транзакция не закрыта, блокирует добавление записей в эту таблицу из других транзакций. На одном из приложений именно этот сценарий изредка повторяется, когда сразу десяток пользователей одновременно запускают процесс массовой обработки данных

И не обязательно два разных пользователя. Сейчас, на другом проекте, этот сценарий стабильно повторяется в рамках одного пользователя в силу особенностей реализации клиентской части. Пользователь нажимает "ок", клиентское приложение создаёт два таска на обращение к API и далее параллельно их выполняет. В итоге, в режиме отладки и при localhost-сервере, эти запросы приходят на сервер достаточно одновременно, чтобы наступить на эту взаимную блокировку.

Добавлено через 1 минуту

Сообщение от Andrey-MSK

Может проще использовать timestamp и при сохранении данных проверять его? Если разные, то вывести пользователю новые данные для сравнения...

Это другой сценарий. Т.е. при сценарии:
1. Взяли сущность из БД.
2. Модифицировали.
3. Сохраняем обратно.

Действительно удобен какой-то вариант 'row version' (timestamp, например). И он корректно работает даже если три обозначенных выше пункта сильно разнесены во времени и выполняются в рамках разных транзакций.

@Usaga · 20.07.2022, 16:10

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

Это другой сценарий. Т.е. при сценарии:
1. Взяли сущность из БД.
2. Модифицировали.
3. Сохраняем обратно.

Это почти чистой воды сценарий работы EF'а) Это значит, что это хорошо)

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

Действительно удобен какой-то вариант 'row version' (timestamp, например). И он корректно работает даже если три обозначенных выше пункта сильно разнесены во времени и выполняются в рамках разных транзакций.

Он мало чем отличается от deadlock. Вот вы выдали UPDATE ... WHERE ID=.. AND ROWVERSION=.., вот вы получили нуль затронутых версий. Опять надо UPDATE выдавать.

Добавлено через 4 минуты
Вариант с оптимистичными блокировками самый оптимальный, на самом деле. На втором месте по адекватности идёт уже SELECT ... FOR\WITH UPDATE. Тут уже другие транзакции с таким же типом лока будут вставать в очередь. Если не злоупотреблять, то вполне себе вариант. Уж точно лучше, чем полная блокировка всей таблицы...

Ну и то, что такие вещи не доступны пользователям EF'а... Проблемы этих пользователей...

@Cupko · 23.07.2022, 14:00

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

Если снизить уровень изоляции, то взаимной блокировки не будет, но и согласованность данных тогда не гарантируется, т.к. 'insert' будет происходить не в том состояние таблицы, в котором она была на момент 'select'.

Что у вас за задача такая, что нужно таблицу лочить целиком?

Если MSSQL - можно юзать SNAPSHOT уровни.

Новые блоги и статьи Все статьи Все блоги /
модель ЗдравоСохранения 8. Подготовка к разному выполнению заданий anaschu 08.04.2026 https:/ / github. com/ shumilovas/ med2. git main ветка * содержимое блока дэлэй из старой модели теперь внутри зайца новой модели 8ATzM_2aurI	Блокировка документа от изменений, если он открыт у другого пользователя Maks 08.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа, разработанного в конфигурации КА2. Задача: запретить редактирование документа, если он открыт у другого пользователя. / / . . .	Система безопасности+живучести для сервера-слоя интернета (сети). Двойная привязка. Hrethgir 08.04.2026 Далее были размышления о системе безопасности. Сообщения с наклонным текстом - мои. А как нам будет можно проверить, что ссылка наша, а не подделана хулиганами, которая выбросит на другую ветку и. . .	Модель ЗдрввоСохранения 7: больше работников, больше ресурсов. anaschu 08.04.2026 работников и заданий может быть сколько угодно, но настроено всё так, что используется пока что только 20% kYBz3eJf3jQ
Дальние перспективы сервера - слоя сети с космологическим дизайном интефейса карты и логики. Hrethgir 07.04.2026 Дальнейшее ближайшее планирование вывело к размышлениям над дальними перспективами. И вот тут может быть даже будут нужны оценки специалистов, так как в дальних перспективах всё может очень сильно. . .	Горе от ума kumehtar 07.04.2026 Эта мне ментальная установка, что вот прямо сейчас, мол, мне для полного счастья не хватает (нужное вписать), и когда я этого достигну - тогда и полный кайф. Одна из самых сильных ловушек на пути. . . .	Использование значений реквизитов справочника в документе, с определенными условиями и правами Maks 07.04.2026 1. Контроль срока действия договора Алгоритм из решения ниже реализован на примере нетипового документа "ЗаявкаНаРаботу", разработанного в конфигурации КА2. Задача: уведомлять пользователя, если. . .	Доступность команды формы по условию Maks 07.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "СписаниеМатериалов", разработанного в конфигурации КА2. Задача: сделать доступной кнопку (команда формы "ЗавершитьСписание") при. . .

@Andrey-MSK 3360 / 2246 / 388 Регистрация: 14.08.2018 Сообщений: 7,589 Записей в блоге: 4
	20.07.2022, 14:01
	kotelok, А какой шанс того, что одни и те же данные будут редактировать два пользователя одновременно? Может проще использовать timestamp и при сохранении данных проверять его? Если разные, то вывести пользователю новые данные для сравнения... 1