Проблема с блокировками
От: peer  
Дата: 09.02.23 12:33
Оценка: :)
Всем привет.

Есть гибридная ef транзакция из примерно 10 инсертов в рамках энтити контекста и одного длинного даппер скл скрипта где идут селекты с апдейтами.

так вот из-за даппер скрипта при многопользовательской работе идут блокировки на уровне базы и некоторые сессии убиваются как жертвы.

Подскажите какие есть паттерны чтобы длинную транзакцию распилить и при этом сохранить тразакционность?
Re: Проблема с блокировками
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 09.02.23 18:58
Оценка:
Здравствуйте, peer, Вы писали:

P>Всем привет.


P>Есть гибридная ef транзакция из примерно 10 инсертов в рамках энтити контекста и одного длинного даппер скл скрипта где идут селекты с апдейтами.


P>так вот из-за даппер скрипта при многопользовательской работе идут блокировки на уровне базы и некоторые сессии убиваются как жертвы.


P>Подскажите какие есть паттерны чтобы длинную транзакцию распилить и при этом сохранить тразакционность?


Мне кажется вы не туда копаете:
1) перепишите запросы, сделайте индексы так, чтобы не было конфликтов блокировок
2) поставьте уровень изоляции read commited snapshot
3) если предыдущие два не помогли, то воспользуйтесь select for update
4) если и он не помог, то ставьте уровень изоляции serializable
5) если serializable слишком жирно и проблема только в этом батче, то используйте app lock
Re[2]: Проблема с блокировками
От: peer  
Дата: 10.02.23 14:11
Оценка:
Здравствуйте, gandjustas, Вы писали:


G>Мне кажется вы не туда копаете:

G>1) перепишите запросы, сделайте индексы так, чтобы не было конфликтов блокировок

тут есть нюансы. в одном месте delete from products where id = @
а в другом идет

update products where id = @

тут наверное только updlock поможет или read snapshot справится?

G>2) поставьте уровень изоляции read commited snapshot


там нет подводных камней, просто свойство базы?

G>3) если предыдущие два не помогли, то воспользуйтесь select for update


это который updlock?

G>5) если serializable слишком жирно и проблема только в этом батче, то используйте app lock


а можно пояснить про какой апп лок речь?
Re[3]: Проблема с блокировками
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 10.02.23 18:52
Оценка:
Здравствуйте, peer, Вы писали:

P>Здравствуйте, gandjustas, Вы писали:



G>>Мне кажется вы не туда копаете:

G>>1) перепишите запросы, сделайте индексы так, чтобы не было конфликтов блокировок

P>тут есть нюансы. в одном месте delete from products where id = @

P>а в другом идет
P>update products where id = @
P>тут наверное только updlock поможет или read snapshot справится?
Видимо да. Потому что при снапшоте будет "кто первый встал, того и тапки", остальные отвалятся.
Правда не очень понятно почему приложение параллельно генерирует запросы на обновление и удаление строк, это что за сценарий?

G>>2) поставьте уровень изоляции read commited snapshot

P>там нет подводных камней, просто свойство базы?
В отличие от обычного read commited используются не блокировки, а MVCC. В итоге кто первый транзакцию закоммитил, тот и прав, а остальные отваливаются.

G>>3) если предыдущие два не помогли, то воспользуйтесь select for update

P>это который updlock?
Да

G>>5) если serializable слишком жирно и проблема только в этом батче, то используйте app lock

P>а можно пояснить про какой апп лок речь?
https://learn.microsoft.com/ru-ru/sql/relational-databases/system-stored-procedures/sp-getapplock-transact-sql
Re[4]: Проблема с блокировками
От: peer  
Дата: 13.02.23 06:58
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, peer, Вы писали:


P>>Здравствуйте, gandjustas, Вы писали:



G>>>Мне кажется вы не туда копаете:

G>>>1) перепишите запросы, сделайте индексы так, чтобы не было конфликтов блокировок

P>>тут есть нюансы. в одном месте delete from products where id = @

P>>а в другом идет
P>>update products where id = @
P>>тут наверное только updlock поможет или read snapshot справится?
G>Видимо да. Потому что при снапшоте будет "кто первый встал, того и тапки", остальные отвалятся.
G>Правда не очень понятно почему приложение параллельно генерирует запросы на обновление и удаление строк, это что за сценарий?

там длинная транзакция с кучей промежуточных расчетов и пока точно непонятно.
но базовая версия, что тесты паралелльно запускаются с разными кейсами, но данные по этой табле одни и те же. Один тест читает, а второй удаляет или апдейтит.
id выше я для простоты написал. там по факту сложный ключ из 3 полей.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.