Разноски, блокировки и NumberSeq

[Logger]

Цитата:

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

Место-то я нашёл. Вопросы классические отечественные: что делать и кто виноват
Проблема как бы разбиралась, но не до конца... причём в одном топике всё закончилось на посте с аналогичной ситуацией.

Ну если нашли место то здесь в комментариях
Блокировка NumberSequence
к исправлениям в коде, пояснен принцип исправлений.

Я думаю у вас нечто схожее.

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

[Helm]

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

Вcё происходит в классе NumberSeqCleanUp
В методе ран создаёт(только создаются) user connection, далее в нём просто вызывается

this.cleanUpSequence(userConnection,numberSequenceTableClean);

В самом cleanUpSequence делается

userConnection.ttsbegin();
numberSequenceTableUpd.setConnection(userConnection);

select forupdate firstonly numberSequenceTableUpd
index hint SeriesIdx
where numberSequenceTableUpd.numberSequence == _numberSequenceTable.numberSequence;

На этом селекте зависает. Дальше идут ещё обращения к другим методам с использованием всё того же UserConnection из run, но это дело десятое, если тут понять.

В примере с Release всё понятно, там были просто ttsbegin-commit и добавлялся connection внутрь их. А здесь как-то неясно мне, подскажите, пожалуйста!

[Helm]

Ещё выяснилась подробность, что оказывается это не в первый раз, а уже бывало когда-то. И тогда лечилось брутфорсом в виде 20-30-кратного создания заказа, пока не удавалось провести разноску. Что только подтверждает данный баг... но конечно так лечить каждый раз не айс