DeadLock. Один сеанс - несколько процессов.

[Владимир Максимов]

Когда возникает DeadLock при работе нескольких сеансов Axapta с этим успешно справляется, просто прекращая один из процессов и эту ситуацию можно обработать по try...catch.

Однако есть ситуации, когда один сеанс открывает несколько процессов. И вот здесь возможны мертвые блокировки примерно такого вида

Сеанс = 1 SPID = 1,2
Сеанс = 3 SPID = 3

SPID 1 блокирует SPID 3
SPID 3 блокирует SPID 2

Axapta такую ситуацию "не видит", поскольку вроде бы нет явной взаимной блокировки. Как следствие, оба сеанса висят, пока вручную не прибьешь один из процессов.

Существует ли способ борьбы с такими ситуациями? В смысле, чтобы не было необходимости вручную отслеживать такие подвисания?

AXAPTA 2.5 SP3 + MS SQL 2005 в режиме совместимости с 2000

[George Nordic]

Ох. На 4ку - нет возможности перейти?

Георгий

[Владимир Максимов]

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

[Logger]

А откуда у вас возникает второе соединение ? Обычно оно для номерных серий открывается и там блокировок не должно быть. - Если вы из обычного сеанса (3 в указанном примере) не редактируете номерные серии.

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

[Владимир Максимов]

Если бы я имел возможность как-то контролировать количество соединений, которое открывает Axapta, то и проблемы не было бы. К сожалению, от меня это практически не зависит. Я не знаю, что именно, какие действия, могут приводить к открытию нескольких процессов в стандартном функционале Axapta.

Под фразой "открывать отдельное соединение" Вы понимаете использование объектов Connection?

Да, номерные серии никто не редактирует. По крайней мере, это была бы очевидная причина подвисания и вопроса не возникло бы...

[Logger]

Цитата:

Сообщение от Владимир Максимов

Под фразой "открывать отдельное соединение" Вы понимаете использование объектов Connection?

Я имел в виду UserConnection() - он открывает новое соединение к базе.

Connection если не ошибаюсь использует то же соединение с бд что и обычные курсоры.

Цитата:

Сообщение от Владимир Максимов

Если бы я имел возможность как-то контролировать количество соединений, которое открывает Axapta, то и проблемы не было бы.

Аналогичная проблема
Я обычно просто по виду запросов пытаюсь угадать что за функционал работает. Или логирование включать на этот момент - тогда можно выловить стек вызовов по запросу.

[sukhanchik]

Номерные серии редактирует сама система - выделяя номера в отдельном Connection-е.
Вот только высвобождает их она в том же Connection...
У нас в связи с этим постоянно табличка NumberSequenceTable лочилась (оракл показывал). Поэтому стандартные решения подобных ситуаций такие (причем это надо сделать во всех компаниях):
1. По возможности избавиться от непрерывных номерных серий. Типа там пакет корреспонденции и все такое. Т.е. непрерывные номерные серии могут быть только там - где не происходит будем так говорить массовое (или частое) создание записей с запрашиванием нового номера.
2. Увеличить (до 50-100) число разово выделяемых номеров для наиболее часто требуемых номерных серий. К примеру - если некая периодическая операция генерит кучу бух проводок - то это будет номерная серия ваучера.

[Logger]

Цитата:

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

Вот только высвобождает их она в том же Connection...
У нас в связи с этим постоянно табличка NumberSequenceTable лочилась (оракл показывал).

Да ! Точно! Это может быть проблемой в описанном случае. Например SPID 3 освобождает номер для номерной серии вызовом NumberSequence::release() (например строка журнала ГК удаляется, рассопопоставление по клиентам/поставщикам идет или фактуру удаляем)

Попробуйте применить вот это - может поможет.
Блокировка NumberSequence

[Владимир Максимов]

Цитата:

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

Номерные серии редактирует сама система - выделяя номера в отдельном Connection-е.
Вот только высвобождает их она в том же Connection...

Да. Нашел, что это делает UserConnection(), который, собственно, и используется только в номерных сериях

Цитата:

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

У нас в связи с этим постоянно табличка NumberSequenceTable лочилась (оракл показывал). Поэтому стандартные решения подобных ситуаций такие (причем это надо сделать во всех компаниях):
1. По возможности избавиться от непрерывных номерных серий. Типа там пакет корреспонденции и все такое. Т.е. непрерывные номерные серии могут быть только там - где не происходит будем так говорить массовое (или частое) создание записей с запрашиванием нового номера.

Их и так почти нет.

Цитата:

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

2. Увеличить (до 50-100) число разово выделяемых номеров для наиболее часто требуемых номерных серий. К примеру - если некая периодическая операция генерит кучу бух проводок - то это будет номерная серия ваучера.

Насколько я знаю, такая настройка появилась только в Ax4.0, а в данном случае речь идет об Ax2.5. Если эта настройка есть и в Ax2.5, то подскажите где?

[sukhanchik]

К сожалению - не знаю - может этого нет в 2.5. Но есть точно в 3.0 SP1:
\Основное\Настройки\Серии документов\Серии документов (форма NumberSequenceTable)

[Владимир Максимов]

Спасибо за "наводку" на номерную серию. Однако я просто не могу себе представить ситуацию, когда бы подобная "круговая" блокировка могла бы возникнуть.

Предположительно, блокировка возникла, когда один пользователь создавал складской журнал, а другой пользователь разносил складской журнал. Если исходить из предположения, что второй процесс - это формирование очередного номера номерной серии при создании складского журнала, то я не понимаю, каким образом остальные процессы могли бы заблокировать таблицы NumberSequence...

Т.е. чтобы произошла такая "круговая" блокировка блокироваться должна одна и та же таблица во всех 3 процессах. Вот этой-то общей таблицы я и не могу определить.

Вобщем, буду ждать очередного "клинча" чтобы уточнить, что же именно блокируется. Какая таблица. К сожалению, не посмотрел во всех 3 процессах.

PS: В Ax2.5 нет возможности настроить "выделенные номера".

[sukhanchik]

Все очень даже логично. Первый - создает журнал. Другой его разносит. В обоих случаях выбирается номерная серия (хотя насколько я понимаю - не всякие складские журналы при разноске генерят номерную серию - или я неправ?). У нас то были финансовые журналы - а там при разноске всегда генерится что-то новое (ну хотя бы пакет корреспонденции).
Т.о. 1-я проводка взяла новый номер и дальше ей нужно сдвинуть счетчик (сделать select forupdate numbersequencetable). Все вроде ничего... Но массовая разноска делалась что логично - в блоке ttsbegin/ttscommit.
Как известно - независимо от уровней вложенности ttsbegin/ttscommit все выполняется в одной транзакции. Соответственно - в тот момент, когда все думали - что уже в БД все записалось (ttscommit стоит) - в БД ничего не записалось - т.к. это был вложенный ttscommit. Получается, что система ждет завершения последнего ttscommit.
Но последний ttscommit стоит ЗА циклом по разноске (мы же хотим все "оптом" разнести - типа либо все либо ничего). Соответственно - следующая итерация ждет завершения первой. Блокировка.
Вывод. Нужно выделять номера пачками - чтобы система не "лезла" каждый раз бы в БД - чтобы цикл отработал весь - до выделения следующего номера.

[Владимир Максимов]

А разве при разноске уже существующего складского журнала идет обращение к номерным сериям? И это та же самая номерная серия (та же запись таблицы NumberSequenceTable), что и при создании складского журнала? Впрочем, все-равно надо будет посмотреть что блокируется на самом деле.

А выделить номера пачками я не могу, поскольку, во-первых, в Ax2.5 нет такого функционала, а, во-вторых, не вижу необходимости. Не понятно, пачку чего (какой номерной серии) надо выделять.

[Logger]

Цитата:

Сообщение от Владимир Максимов

А разве при разноске уже существующего складского журнала идет обращение к номерным сериям?

По идее может.
по крайней мере в 3.0 можно настроить складской журнал так чтобы ваучер выделялся уже в момент разноски (есть настройка InventJournalTable.VoucherDraw - выделять ваучер по мере ввода или при разноске)
В 2.5 - не знаю.

Плюс как указал sukhanchik - та же корреспонденция по ГК.

[sukhanchik]

Цитата:

Сообщение от Владимир Максимов

А разве при разноске уже существующего складского журнала идет обращение к номерным сериям?

Когда я говорил про складские журналы - я имел в виду - что есть складские журналы типа прибыли/убытки или инвентаризации - которые генерят ГК-шные проводки, а значит по определению обращаются к номерной серии.
Журналу переноса очевидно - смотреть туда нечего (это по логике - но я детально я не изучал процесс его разноски), хотя при создании строк журнала переноса - номерная серия точно используется - чтобы создать складские проводки.

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

[sukhanchik]

Цитата:

Сообщение от Владимир Максимов

А выделить номера пачками я не могу, поскольку, во-первых, в Ax2.5 нет такого функционала, а, во-вторых, не вижу необходимости. Не понятно, пачку чего (какой номерной серии) надо выделять.

Вот про "не вижу необходимости" я уже расписал - что есть случаи - когда это помогает.
То что нет такого функционала - да - это плохо... но это к мелькавшим разговорам на форуме о проблемах поддержки старых версий и легкости/сложности апгрейда.
А вот как раз понять - какую номерную серию нужно выделять пачками - можно. У вас возникают блокировки при создании строк складского журнала и при его разноске (так?). Если так, то смотрим - какие номерные серии участвуют в этом процессе. Как минимум - участвует номерная серия самого журнала (InventJournalTable.JournalId), потом я смотрю в строках журнала переноса (правда в 4-ке) есть поле Voucher - которое тоже заполняется, ну и наконец - серия, которая заполняет InventTransId.
Итого - на беглый взгляд - у нас 3 номерных серии, на которые надо пристально посмотреть.
Или же есть вариант - отладчик. Но он хорош, когда четко известна последовательность действий, которая приводит к блокировке. Тогда можно поймать ту единственную, которая приводит к блокировке.

[Logger]

1-й.
Юзер 1 разносит журнал ГК - происходит запись в LedgerTrans - обновляется запись в LedgerBalances - это SPID = 1. Параллельно выделяется номер в номерной серии (например ваучер, пакет корреспонденции и.т.п.) блокоровка на NumberSequenceTable - NumberSequenceList - SPID = 2

Юзер 2 Рассопоставляет проводки по расчетам с клиентами / поставщиками. Происходит генерация проводок в ГК - соответсвенно блокировки LedgerBalance и возвращение номера из непрерывной номерной серии (ваучер) блокировка на NumberSequenceTable - NumberSequenceList SPID = 3

клинч : юзеры могут зацепиться на таблицах LedgerBalances и на номерных сериях NumberSequenceTable .

2-й
На складских журналах наверно тоже может возникнуть нечто подобное на связке InventSum - NumberSequenceTable
Первый юзер создает строку в складском журнале в режиме авторезервирования - дергается InventSum и NumberSequenceTable - в разных SPID 1 и 2
Второй юзер удаляет похожую строку, дергаются те же таблицы но уже одним соединением SPID = 3.

[Logger]

Самое интересное - что при работе с журналом переноса тоже дергаются ваучеры (прописываются в строчку при вставке или при разноске) - хотя в дальнейшем и не используются

[sukhanchik]

Цитата:

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

Самое интересное - что при работе с журналом переноса тоже дергаются ваучеры (прописываются в строчку при вставке или при разноске) - хотя в дальнейшем и не используются

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

[fed]

Цитата:

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

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

Потому что ваучер - это не ссылка на главную книгу (как многие думают), а идентификатор хозоперации. И во многих местах в системе ваучер используется БЕЗ создания проводо ГК.

Ну и кстати возвращаясь к теме топика - по моему опыту - барабашек не бывает. Я такие блокировки видел раза 2-3 и во всех случаях они были связаны либо с использованием метода NumberSeq:release (о котором в топике уже написали), либо с тем что в доработках использовался доступ к numberSequenceTable/numberSequenceList в основной сессии.
Так что я бы для начала исправил ошибки в numberSeq::release (как рекомендовали уже), а потом посмотрел бы в коде на слое USR любые обращения к numberSequenceTable/numberSequenceList.