Здравствуйте, peer, Вы писали:
P>Всем привет.
P>Есть гибридная ef транзакция из примерно 10 инсертов в рамках энтити контекста и одного длинного даппер скл скрипта где идут селекты с апдейтами.
P>так вот из-за даппер скрипта при многопользовательской работе идут блокировки на уровне базы и некоторые сессии убиваются как жертвы.
P>Подскажите какие есть паттерны чтобы длинную транзакцию распилить и при этом сохранить тразакционность?
Мне кажется вы не туда копаете:
1) перепишите запросы, сделайте индексы так, чтобы не было конфликтов блокировок
2) поставьте уровень изоляции read commited snapshot
3) если предыдущие два не помогли, то воспользуйтесь select for update
4) если и он не помог, то ставьте уровень изоляции serializable
5) если serializable слишком жирно и проблема только в этом батче, то используйте app lock
Здравствуйте, 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
Здравствуйте, 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 полей.