Добрый день. Иногда с талкиваешься с тем, что z-программы, написанные для любимых пользователей, сильно долго работают и вроде как уже достаточно оптимизированы, но времени для отработки не хватает и вылетают по таймауту. Можно ли как-то в коде сбрасывать таймаут, что б прога работала пока не закончит, либо пока не надоест и не сбросишь вручную...?
Что значит слетают по таймауту? Если с дампом TIME_OUT, то параметр отвечающий за это время настраивается в профиле сервера приложений и чтобы его увеличить, вам надо обратиться к своему базису.
Цитата: Sam від Лютий 03, 2011, 03:04:05 ПП
вам надо обратиться к своему базису.
Но они могут и отказать, причина в том что количество диалоговых процессов в системе ограничено, если их забить вашими программами то по факту вы подвесите всю систему. Как обходной метод если у вас в цикле отрабатывают несколько разных селектов, поставьте между ними вызов COMMIT WORK, это сбрасывает счетчик времени процесса.
спасибо. Интересно, что под парой пользователями программа в дамп не падает и судя по тому, что она уже часа 2 работает как я ее запустил, то и подо мной тоже)
Цитата: Greed від Лютий 03, 2011, 03:36:25 ПП
спасибо. Интересно, что под парой пользователями программа в дамп не падает и судя по тому, что она уже часа 2 работает как я ее запустил, то и подо мной тоже)
Возможно эти пользователи работают на другом сервере приложений, где время таймаута больше.
В общем вам надо обсудить этот вопрос с базисниками, чтобы найти оптимальное решение.
не, они на том же работают. Базисники разводят руками:"копай свою прогу..."
Тут вопрос комплексный. В зависимости от сложности запроса и размеров таблиц время выполнения может быть разным и если ваша программа работает как должна и оптимизировать её дальше не представляется возможным, то возможно стоит обсудить увеличение времени работы диалогов с базисом.
Кстати мы так и не узнали с какой ошибкой падает ваша программа...
Цитата: Semen F. від Лютий 03, 2011, 08:48:52 ПП
Кстати мы так и не узнали с какой ошибкой падает ваша программа...
Кстати, да... если можно кусок начала дампа в студию... а то параметр времени выполнения на процесс оно глобальное и не может так быть чтобы у одних работало у других нет.
у меня в дамп не падает, вот есть только то, что у пользователя...
Цитата: Greed від Лютий 04, 2011, 10:57:20 ДП
у меня в дамп не падает, вот есть только то, что у пользователя...
Ну да времени не хватило... но тут еще надо смотреть с какими параметрами запускают, поэтому них падает у тебя нет.
Ну об этом дампе мы и подумали.
Это именно дамп по ограничению времени выполнения диалогового запроса. То что у вас не падает а у пользователя падает может быть обусловлено разными настройками на разных серверах приложений. Если конечно вы указали те же параметры запроса что и пользователь.
Если у вас в системе только 1 сервер, на котором все работают, то тут причина неясна.
Сам недавно стал сталкиваться с таким странным факто, что у меня на серверах приложений с небольшим лимитом времени выполнения процессы не падают. Почему, я пока не разобрался.
В любом случае вам придется решать вопрос с базисом и приходить к некому времени выполнения, которое устроит и вас и базис.
коммит верк счетчик таки сбрасывает) В общем в исключительных случаях его применить можно.
Цитата: Greed від Березень 01, 2011, 10:53:26 ДП
коммит верк счетчик таки сбрасывает) В общем в исключительных случаях его применить можно.
Сбрасываться то сбрасывается, но там еще кроме этого оно делает следующее:
Выполняет запуск всех подпрограмм, которые вызываются с использованием инструкций вида PERFORM <имя подпрограммы> ON COMMIT и всех функциональных модулей объявленных как CALL FUNCTION <имя модуля> IN UPDATE TASK.- Вызывает инициирование событий для службы Object Services. Поэтому если у вас есть фоновые процессы, запускающиеся по событию, то именно эта операция генерирует все заявленные в блоке обработки события.
- Обрабатываются все SAP блокировки, установленные в текущей программе по значению формального параметра _SCOPE для соответствующих функций блокирования, происходит снятие таких блокировок.
- Закрывается текущий LUW блок и все курсоры на уровне базы данных.
- Вызывается событие TRANSACTION_FINISHED, что устанавливает для системного класса CL_SYSTEM_TRANSACTION_STATE значения COMMIT_WORK.
так что если вам выше описанные действия не беспокоят.. то можете и через COMMIT WORK делать сброс счетчика времени выполнения транзакции.