Petro123сначала select update убрать.
А тогда и очереди не понадобятся )
Вот и о том же )
JDSт.е. блокировка накладывается только на момент изменения данных, а то и вообще просто в контексте самого апдейта (без select for update)

function set_flag return number
is
n_res number;
begin
update mytable_with_flag -- упрощенно
set flag = 1
where flag = 0;

if sql%rowcount = 0 then
n_res := 0; -- флаг уже стоит
else
n_res := 1; -- флаг выставили
end if;

return n_res;
end;

JDSкоммититься не забываем )

xifrА чем это принципеально отличается от select update,
ведь в случае неожиданного разрыва коннекта, будет тоже самое.
Абсолютно верно - практически ничем, кроме того, что можно выставить флаг без select for update (просто мелкое замечание)
Насчет неожиданного разрыва тоже писал - надо убрать управление блокировками напрямую из java или какого-либо другого СП
и как вариант, запускать процедуры джобами )

urvasВот Вы никак не хотите понять, что база не может сама принимать решение о старте какого-либо её, базы, внутреннего приложения. В моём случае это внешний сигнал из Java, а поэтому никакие джобы не помогут - они либо сигнала не увидят (если флаг не выставить), либо дружною толпою начнут обработку (если доверить вызов джобов внешнему приложению).

По порядку:
1. Java-приложение дает базе сигнал на запуск ХП в виде создания джоба (т.е. по сути оно поставило задание в очередь) - все дальше оно может хоть отваливаться, хоть еще 100 джобов попытаться поставить. Чем это не сигнал базе? )

2. Внутри самой ХП прописывается механизм выставления флага. Т.е. джоб запускает процедуру, а уже процедура, выставляет флаг, если у нее не получилось выставить флаг, значит кто-то уже выставил флаг ранее (другой джоб) в этом случае (смотря что нужно) процедура или просто завершается (возможно с протоколом и т.п. в общем как душе угодно), или ждет завершения уже работающей сессии может там через алерты/пайпы (надо покурить про них), второй вариант сложнее, когда надо ждать завершения.
В каком месте здесь может быть " они либо сигнала не увидят (если флаг не выставить), либо дружною толпою начнут обработку (если доверить вызов джобов внешнему приложению)" ?
В том, что таким механизмом можно точно сделать обработку по очереди, а не сразу всей толпой, в этом не сомневаюсь.

Единственное, возможно, хотите сказать, что есть требование, что выполняем ХП 100% только в том случае, если java-приложение имеет коннект вплоть до завершения выполнения этой самой ХП, в противном случае, необходимо откатить все назад.

Плюс требования к скорости, если надо все делать оч. быстро, то да с джобами, не очень имхо.

Еще вариант (немного изуверский, но в некоторых ситуациях можно попробовать):
1. Никакой флаг блокировки не выставляется
2. Каждое java-приложение обрабатывает данные во временной таблице (т.е. сначала забирает данные во временную таблицу и крутит их как угодно никто никого опять же тоже не блокирует, т.к. каждый работает со своими данными)
3. Сбрасывают изменения в постоянную таблицу и вот тут, кто первый сбросил, того и тапки ) (отследить можно по номеру изменения например на сиквенсе, который мы забираем при подхвате данных во временную таблицу)
Возможно этот же вариант, можно попытаться реализовать, задав соответствующий уровень изоляции транзакции, но с этим не приходилось эксперемнтировать )
Если Java-приложение отваливается, то оно никого не держит - только данные во врем. табличках, которые автоматом почистятся.

Понятно, что если надо продублировать много данных из разных таблиц, если подразумевается, что одновременно могут работать сотни сессий в таком ключе, если необходимо максимальное время отклика, а не переливание из таблицы в таблицу, то удовольствие сомнительное )

maytonЧувак. Найми себе аналитика + разработчика Java/Oracle
Спасибо, денег только дайте, обязательно найму, хоть тыщу аналитиков и три тыщи старших помощников младших аналитегов )

Petro123угу. Особенно под пользователем sys.
Вы-таки шото имете против джобов? ) При чем тут сис непонятно )
Petro123, и чо вы прицепились к человеку зачем, да зачем, по всей видимости речь идет как раз не об олтп-операциях, а просто о запуске некой длительной обработки в контексте конкретной задачи, совсем не факт, что так будет построена вся система, даже для маленьких коротких запросов, хотя фиг знает конечно )