DAX2009 Странное поведение пакетного сервера

[Raven Melancholic]

Добрый день.
Столкнулся с непонятным поведением пакетного сервера при обработке задачи, выполняющейся раз в сутки. Может быть кто-то сталкивался и знает решение или хотя бы может подсказать в какую сторону копать.
Сегодня это было пакетное задание (BatchJob), у которого несколько задач (Batch) выполняющихся последовательно, каждая после успешного завершения предыдущей, но время от времени проявляется и для тех, у кого только одна задача. Ошибка неустойчивая
Запланированное время запуска 0:30. Вчера ночью все задачи отработали, были сделаны корректные записи в истории задач (BatchHistory) последняя завершилась в 4:00:57 и в 4:02:07 была создана запись в BatchJobHistory.
Тут же в 4:02:11 все задачи одновременно вдруг были запущены заново, завершились они в разное время и были созданы записи в BatchHistory, но не было создано записи в BatchJobHistory.
Сегодня же в 0:30 задание запустилось, отработало всего 1 минуту, создалась запись в BatchJobHistory, к которой привязались записи BatchHistory, которые были созданы вчера.
Пока даже нет никаких идей чтобы воспроизвести кейс, в котором было бы такое поведение.

[Raven Melancholic]

Судя по всему, поведение похоже на то, что в теме:
Пакетные задания - batchConstraint (AX 2012 R2)
правда там немного наоборот - не все закончилось выполняться, а запустилось то, что должно еще ждать, но

Цитата:

расследование показало, что MS SQL некорректно выполняет сформированные в данном методе запросы с exists/notexists join когда они выполняются одновременно с другими запросами на обновление Batch

наводит на размышления. Если это, действительно так, то работа двух пакетных серверов одновременно с методами serverProcessFinishedJobs и serverProcessDependencies в случае, когда exists/notexists частично игнорируют, а частично учитывают транзакцию может привести к тому эффекту, который мы получили.

[gl00mie]

Цитата:

Сообщение от Raven Melancholic

Если это, действительно так, то работа двух пакетных серверов одновременно с методами serverProcessFinishedJobs и serverProcessDependencies в случае, когда exists/notexists частично игнорируют, а частично учитывают транзакцию может привести к тому эффекту, который мы получили.

Посмотрите на исправления класса BatchRun, выпущенные для AX 2012 R2 в рамках KB 3216955 "Continuous dead locks in batch tables", возможно, имеет смысл портировать их на AX 2009. Вкратце, там код работы с таблицами пакетной инфраструктуры обрамили в захват и освобождение mutex'а на уровне СУБД

#define.BatchRunServerTaskLock("BatchRunServerTaskLock")
ReqReaderWriterLock lock;
// ...
lock = ReqReaderWriterLock::construct();
lock.enterWriterLock(#BatchRunServerTaskLock);
try
{
    // обновление Batch-таблиц
}
catch (Exception::Deadlock)
{
    lock.exit(#BatchRunServerTaskLock);
    throw Exception::Deadlock;
}
catch
{
    lock.exit(#BatchRunServerTaskLock);
    throw Global::error("@SYP4316158");
}
lock.exit(#BatchRunServerTaskLock);

[Raven Melancholic]

Цитата:

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

Посмотрите на исправления класса BatchRun...

Вот что значит паника. Я активно смотрел на этот класс в DAX2012 R3, но именно этого не заметил - зафиксировал только то что появилось readCommittedLock(true), а на такое, бросающегося в глаза, даже не обратил внимания.

[skycap]

/// <summary>
/// Check whether or not to enable batch run server task lock from SysGlobalConfiguration table.
/// </summary>
/// <returns>
/// Whether or not to enable batch run server task lock.
/// </returns>
private static boolean isBatchRunServerTaskLockEnabled()
{
    SysGlobalConfiguration sysGlobalConfig;

    #define.ConfigName_EnableBatchRunServerTaskLock('EnableBatchRunServerTaskLock')

    select Value from sysGlobalConfig
        where sysGlobalConfig.Name == #ConfigName_EnableBatchRunServerTaskLock;

    return (sysGlobalConfig && sysGlobalConfig.Value == 'True') ? true : false;
}

В таблице SysGlobalConfiguration не нашел соответствующей записи (чистое приложение DAX 2012 R3 с последними обновлениями). Планирую добавить ее руками в SQL. Есть соображения по этому поводу?

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

Как предположение.

В Ax2009 было введено UTCDateTime. Часовые пояса. У Вас время запуска - около полуночи. Может, с настройками текущего часового пояса проблемы?

Если сдвинуть время начала задания так, чтобы даже без учета часового пояса дата начала запуска была в тот же день, то проблема пропадет?

[Raven Melancholic]

Цитата:

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

Может, с настройками текущего часового пояса проблемы?

Было самым первым предположением, но не подтвердилось.

[gl00mie]

Добавляйте Широкое распространение в той же D365O получил т.н. flighting-режим работы функционала, когда по умолчанию он выключен, но может быть включён на лету с помощью записи в специально обученной таблице. См., к примеру, kurthatlevik: Dynamics 365F&O – Enabling new hidden functionality (SYSFlighting). Тут похожая ситуация.