Написание демона: бесконечный цикл или постоянный перезапуск?

Добрый день, господа.

Существует задача написать "демона" на процедурах оракла, с использованием oracle schedules. Я вижу 2 возможных пути реализации:

1. Бесконечный цикл с dbms_lock.sleep(5) в конце (если делать нечего, чтобы не расходовать ресурсы почём зря)
2. Постоянный перезапуск задания: запустились, если есть что делать - работаем, если нечего - останавливаемся и запускаемся повторно по расписанию через 5 секунд

Я уже реализовал вариант 1. Но он выглядит неудобным, потому что есть шансы наступить на очень клёвые грабли с блокировками (уже наступал). Поэтому присматриваюсь к варианту 2, но не уверен, насколько дорого будет обходиться постоянный старт-стоп.

Вопрос: какой вариант выбрали бы вы и почему? Или может есть ещё альтернативные? "Дорогой" ли вариант 2, по сравнению с 1?

zerkms
если есть что делать

Ключ от сундука с ответами зашифрован в ответе на эту фразу.

-2-,

Если вы намекаете на то, что эту задачу можно переписать на AQ, то нет, в данном случае не получится.

Если не намекаете, тогда: пускай у нас есть "демоны" 2х типов:

1. Работает с удалённым ресурсом через http: делает запрос и на основе ответа запускает или не запускает процедуры
2. Работает с локальными таблицами: выполняет запрос к таблицам, на основе выборки запускает или не запускает процедуры

может подойдёт вариант апдейта какого-нибудь флага в конфигурационной таблице в 1 с последующим вызовом триггера, который запустит скедулер, который в свою очередь в конце отработки скинет флаг в 0...?

Таким образом, не будет пустых стартов-стопов

но это лишь предположение

Tolka,

Если операция запуска scheduler job в оракле "дешёвая" (а именно это и есть основное, что я хотел бы выяснить в данном треде), тогда решение с постоянными старт-стопами меня устраивает, потому что имеет кучу достоинств, по сравнению с вариантом с бесконечным циклом.

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

zerkms,

я когда писал сообщение не видел вашего уточняющего ответа

к 1му варианту с http триггер, конечно, ни к чему

Tolka,

Ок. В свете того комментария ваш выбор каким был бы?

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

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

а по цифрам...насколько тяжел запуск с такой периодичностью...я ничего сказать не могу.

zerkms,

1. сомневаюсь в разумности полагаться на 5ти-секундную стабильность ответов "удаленного ресурса". Если же он не столь удаленный, то часто есть варианты.
2. изменение локальных таблиц - сам ларри использует очереди в стримсах, cqn и т.п.

Безотносительно к архитектуре.
Шедулер позволит стандартно управлять частотой, "включенностью", средства логирования, перезапуск по ошибкам,...
Свой процесс позволит дешевле сохранять состояние между циклами, кастомно управлять частотой, "включенностью", средства логирования, перезапуск по ошибкам,... и увлекательно лавировать по еще нехоженным граблям.

-2-,

Вариант со своим процессом у меня уже реализован и вполне себе успешно работает. Но недавно случился конфуз:

Пускай демон работает с пакетом А. Так что пакет А заблокирован, как зависимый. В пакете есть локальная переменная типа tbl%rowtype. В таблицу был добавлен столбец (про %rowtype я забыл, потому что пакет объёмный). Через некоторое время некоторый клиент (просто клиент, из языка программирования) попытался вызвать пакет процедуры А. Оракл увидел, что зависимости от А (таблица) были изменены -> надо перекомпилироваться. А перекомпилироваться не смог, потому что пакет заблокирован. Как результат: наступили на клёвую блокировку, которую я искал некоторое время :-) Вариант с постоянными перезапусками такого не допустил бы.

-2-
Свой процесс позволит дешевле сохранять состояние между циклами, кастомно управлять частотой, "включенностью", средства логирования, перезапуск по ошибкам,... и увлекательно лавировать по еще нехоженным граблям.

Состояние между циклами мне не нужно, средства oracle scheduler для управления частотой запуска меня устраивают, логгирование тоже есть, в шедулере из коробки и моё, перезапуск - старт-стоп решение чем не перезапуск... Короче говоря - все эти "преимущества" или не существенны в моём случае, или не преимущества совсем :-)

Так что вопрос: насколько дорого ораклу запускать новый процесс шедулер джоба?

-2-
1. сомневаюсь в разумности полагаться на 5ти-секундную стабильность ответов "удаленного ресурса". Если же он не столь удаленный, то часто есть варианты.

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