a_voroninВот тут самое оно перевести таблицу в InMemory и такое понятие как блокировка вообще исчезнет как класс, но вы версию не указали.Ээээ, "исчезнет как класс"?
Блокировка - это не какая то "бага", которую поправили внедрением функционала InMemory, это фцнуциорал СУБД, гарантирующий атомарность изменения данных. Разумеется, для InMemory таблиц блокировки точно такие же, разве что реализованы другим кодом. Иначе были бы перекорёженные записи, где половина полей изменены одним процессом, а половина другим.

ТС нужно просто делать блокировки короче, если это возможно. Например, без внешней транзакции, внутри простого апдэйта.

invmalexeyvgЭэээ, "исчезнет как класс"?Исчезнет. In-memory таблицы lock-free - применяются оптимистические блокировки. Соответственно, при конкурентном изменении одних и тех же строк, возникает конфликт и одна из транзакций откатывается.А, точно.

Просто это как бы базовое ограничение - "необходимо обеспечить атомарность". Так что не поможет, даже можно не читать про InMemory, что бы это понять. А то, что там откатывается, а не ждёт, я не помнил, не работаю с InMemory, но это уже детали

aleks222Кто на ком стоял?

ЗЫ. Интересно, как "возникает конфликт", если "блокировки нет"?Ну, не придирайтесь к словам :-)
Блокировки нет, но ждать прога не будет, просто отвалится с ошибкой.

Владислав Колосовinvm,

не пойму вопрос. Откуда появится нарушение?Две транзакции сделали обновление строки, изменили поле field = field + 1

Значение field было равно 100
Каждая транзакция в своей копии строки установила значение поля 101.
Далее первая записала 101, второй что записывать, тоже 101? Это нарушение целостности данных. Потому что выполнение двух запросов field = field + 1 должно увеличить field на 2, а не на 1.

Владислав Колосов,

https://docs.microsoft.com/ru-ru/sql/database-engine/transactions-in-memory-optimized-tables

a_voroninalexeyvgпропущено...
Две транзакции сделали обновление строки, изменили поле field = field + 1

Значение field было равно 100
Каждая транзакция в своей копии строки установила значение поля 101.
Далее первая записала 101, второй что записывать, тоже 101? Это нарушение целостности данных. Потому что выполнение двух запросов field = field + 1 должно увеличить field на 2, а не на 1.

Одна транзакция валиться, делает retry, обновляет на 102 . Скажем так, побыстрее это шуршать будет, чем то, что сейчас имеем на физической таблице.Разве быстрее второй транзакции делать всё заново, после того, как завершиться первая, чем подождать до конца первой? Ведь ожидание-то одинаковое, в любом случае второй траназкции придётся ждать окончания первой, она же раньше не сможет продолжиться.

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

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

a_voroninВ данном случае надо было задействовать sequence и непонятно почему это было не сделано. Если это невозможно из-за низкой версии, то надо предгенерить значения или использовать очередь в брокере, что возможно уже давно и дает параллельность.Да, или IDENTITY
Но это уже другой вопрос.
Может, у них какой то особый алгоритм формирования этого номера, определяемый, скажем, внешними правилами (скажем, государственными нормативными актами, или давно принятыми локальными нормативными актами).