Блокировка таблицы LedgerBalancesTransDelta (AX 2009)

[NatKo]

Добрый день!

Используется:
Приложение: АХ 2009 (SP1 + RU5)
База: SQL Server 2005

Проблема:
При создании проводок ГК происходит блокировка таблицы LedgerBalancesTransDelta.
Возникает ошибка: Невозможно удалить записть в Сальдо ГК - Аналитики (LedgerBalancesTransDelta). Счет ГК: , . Тупиковая ситуация. Один или несколько пользователей одновременно блокировали всю таблицу или ее часть.

Блокировка происходит периодически при работе у разных пользователей. Воссоздать ситуацию искусственно пока не удалось.

Операции, вызывающие ошибки, самописные, были перенесены с ах3, возможно что-то не учтено при переносе.
Но удаление записей в таблице LedgerBalancesTransDelta происходит в стандартном методе LedgerBalancesTransDelta::deleteTemporaryDeltaRecords(userTTSId, connection). Вызывается метод так же стандартно из класса LedgerVoucher.

В чем может быть проблема?

[Vadik]

Вот это уже интересно. Модификации на LedgerBalancesTransDelta или классах разноски в ГК есть? Локализовать ошибку (например, посмотреть граф дедлока) не пробовали?

[NatKo]

Модификаций на самой таблице LedgerBalancesTransDelta - нет.
На классах разноски ГК (LedgerVoucher*) - есть. Добавлена проверка на аналитику ЦЗ и добавлены параметры для LedgerTrans, которые не затрагивают основной логики формирования проводок.
Классы LedgerBalances* - стандартные.

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

[Vadik]

Ну, если ничего подозрительного в классах разноски не видно, я бы поизучал граф дедлока и начал с того, что выяснил, с какой операцией (INSERT или DELETE) мы при удалении "схлестнулись"

[PavelX]

Столкнулся с такой же проблемой. Если кому-нибудь понадобится, то решил следующим образом:

В конструкторе класса LedgerBalancesPostingList меняем значение флага isUsingSecondUserConnection:

    //#define.isUsingSecondUserConnection(false)
    #define.isUsingSecondUserConnection(true)

Далее, для закрепления эффекта можно еще в том же классе поправить метод transferTempDeltaRecsToLedgerBalances:

//LedgerBalancesTransDelta::transferTempDeltaRecsToLedgerBalances(userTTSId);
LedgerBalancesTransDelta::transferTempDeltaRecsToLedgerBalances(userTTSId, connection);

Благодаря этим изменениям вся работа с таблицей LedgerBalancesTransDelta начинает вестись не через основное клиентское подключение а через отдельное, тем самым время блокировок существенно сокращается.

Честно говоря, я так до конца и не разобрался в чем конкретно была причина данной ошибки. Такое впечатление что при длинных транзакциях таблица LedgerBalancesTransDelta блокировалась целиком. Но тем не менее после этих изменений ошибки исчезли.

[trud]

прошу прощения, но это до первого аварийного завершения клиента будет работать?

[ansoft]

Цитата:

Столкнулся с такой же проблемой. Если кому-нибудь понадобится, то решил следующим образом:

Могу ошибаться пара лет прошла, но что то подобное было и у нас...

Скажите а в БД SQL READ_COMMITED_SNAPSHOT ON?
LedgerBalancesTransDelta OCC = Yes?

Был такой документ Planning database configuration for Microsoft Dynamics AX.pdf
В нем есть ряд рекомендаций по настройке... могу ошибаться, но при переходе с 3.0 на 2009 мы его включили и получили сюрпризы в части доработок 3.0, решили отключить и получили сюрпризы подобные вашим... тогда включили и более не отключали, допиливая доработки 3.0.

[PavelX]

Цитата:

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

прошу прощения, но это до первого аварийного завершения клиента будет работать?

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

Цитата:

Скажите а в БД SQL READ_COMMITED_SNAPSHOT ON?
LedgerBalancesTransDelta OCC = Yes?

Спасибо, сейчас посмотрел в продакшене действительно READ_COMMITED_SNAPSHOT OFF. Видимо были у клиента причины так сделать.