2 Batch сервера - ошибка

[SHiSHok]

Ax3.0SP2 + MS SQL2kSP3.
На одной машине (сервер), под одним логин, работают 2 пакетных сервера. Клиенты, в которых запущены пакетные группы, - Fat, пользватели (логины аксапты) разные. Вот работают себе эти 2 пакетника, обрабатывают 2-е разные пакетные группы, все хорошо и вдруг один оставливается с сообщением : "Невозможно выбрать запись в 'Пакетные проводки ' ('Batch') Приоритет: 0, .Тупиковая ситуация. Один или несколько пользователей одновременно блокировали всю таблицу или ее часть.". И так переодически.
никто не сталкивался? что можно предпринять?

[Lucky13]

Сталкивался. Посмотрел код стало понятно, что блокировка происходит, когда производится update статуса в таблице Batch. Сделал следующее: уменьшил частоту сканирования таблицы Batch (по умолчанию было 30 сек, поставил 600 (10 мин)). Ошибка стала появляться значтельно реже (после изменения появилась всего один раз). Еще убрал все что касается статуса Ошибка т.к. не нашел что в нем полезного (если пакетный класс сваливается по exception, то статус пакета становится Error и пакет больше не запускается пока этот статус не сменишь руками).

[SHiSHok]

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

[Lucky13]

Транзакции я тоже менял, не помогло. Потом подумал - зачем раз в тридцать секунд искать в таблице, не нужно ли что-нибудь запустить, если у нас минимальный интервал запуска пакетов - 20 минут. 20 ставить не стал, поставил 10. Наверное не очень красивое решение, но зато помогает

[KiselevSA]

У нас задачи пакетной обработки разделены по пакетным группам. Каждый пакетный сервер обрабатывает задания только своей группы. Может поэтому у нас блокировок практически нет?

[SHiSHok]

Анннналогично. Пакетные серваки исполняют 2 разные пакетные группы, да и пакетные группы по своим функциям совершенно из разных опер (в общем-то с пересечением функционала проблем не возникало). Еще такой ньюансик: вылетает постоянно пакетник у которого название Пакетной Группы "ниже" (при сортировке по возрастанию) и так вышло RecId больше. Как то странно уж очень.

[KiselevSA]

Нашел правки в классах BatchRun и RunBaseBatch.
В runJob первого есть код проверки
if (batch.JournalId)
runBaseBatch.batchRecId(batchId);
//после runBaseBatch.run();
Во втором:
возврат RecId выполняемой задачи

[Vadik]

Цитата:

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

Транзакции я тоже менял, не помогло. Потом подумал - зачем раз в тридцать секунд искать в таблице, не нужно ли что-нибудь запустить, если у нас минимальный интервал запуска пакетов - 20 минут

Цитата:

Наверное не очень красивое решение

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

Можно сделать чуть тоньше - увеличить интервал очистки (смены статусов у пакетов, зависших в статусе "Выполнение", BatchRun.cleanUpExecuting()), лочится в основном там и на BatchRun.search()

Плюс мелкий тюнинг индексов на Batch

На выходные в таком режиме крутилась молотилка из шести пакетных серверов на шесть групп, периодичность у пакетов - минута (своего рода "песочница" - пакеты ничего полезного не делают)

[SHiSHok]

Цитата:

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

Нашел правки в классах BatchRun и RunBaseBatch.
В runJob первого есть код проверки
if (batch.JournalId)
runBaseBatch.batchRecId(batchId);
//после runBaseBatch.run();
Во втором:
возврат RecId выполняемой задачи

у нас пакетные журналы не используются.

[SHiSHok]

Цитата:

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

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

Можно сделать чуть тоньше - увеличить интервал очистки (смены статусов у пакетов, зависших в статусе "Выполнение", BatchRun.cleanUpExecuting()), лочится в основном там и на BatchRun.search()

Плюс мелкий тюнинг индексов на Batch

похоже индекс под Search делали, да зачемто только createdDate,Time туда влепили. Но я "batch = this.search();" убрал из транзакции. А вот СleanUpExecuting нехорошо может залочить своим while select forupdate - убрал транзакцию внутрь условия. Теперь понаблюдаем.

[SHiSHok]

отчет: почти неделя работы 2-х пакетных серверов без единой ошибки. можно с уверенностью (95% ) сказать что блокировались записи в BatchRun::cleanUpExecuting
Думаю не лишним будет поправить тем кто использует больше одного батч сервера:

server static public void cleanUpExecuting(boolean checkSession = false)
{
    Batch _batch;
    Batch _batch4update; // SHiSHok


    while select _batch
        index hint StatusIdx 
        where _batch.status      == BatchStatus::Executing  &&
              _batch.sessionIdx  >  0
    {
        if (! _batch.isSessionActive(checkSession))
        {
// SHiSHok , 20061123 stability turnung-->
            ttsbegin;
            _batch4update=batch::findRecId(_batch.RecId,true);
            _batch4update.status = BatchStatus::Waiting;
            _batch4update.update();
            ttscommit;
// SHiSHok <--
        }
    }
}