1. Для каких именно целей используется select for update? (т.е. на какое время удерживается блокировка)
2. Вполне возможно, что в таком раскладе лучше использовать оптимистическое блокирование, т.е. блокировка накладывается только на момент изменения данных, а то и вообще просто в контексте самого апдейта (без select for update), если же данные с момента чтения изменились, выдается эксепшн, мол. пока вы чесали репу, данные уже были изменены, прочитайте заново и тогда уж правьте по-новой )

urvasСуществуют ситуации, когда любое из них должно запустить ХП в Oracle, но только первое достучавшееся и только один раз, для чего ХП (или приложение) должна выставить флаг (изменить запись в таблице). SELECT … FOR UPDATE может гарантировать блокировку и защиту от многократного изменения.
А. Для запуска ХП. Так может тогда вообще отказаться от таблицы, в которой фиксятся запуски? А сразу смотреть all_jobs? (если уже запущено, то и не запускаем). А уже в самой процедуре вести протокол запусков, если он вообще нужен.

urvasПервый захвативший тем самым не даёт другим прочитать значение флага, независимо от того разрешительный или запретительный он. Если необходимо изменить флаг, то меняет. Без update все могут прочитать разрешительный флаг и отработать код, а этого и не надо.
Это понятно - так и говорю, мол может запускать не напрямую, а через джобы и смотреть при этом, не запущен ли уже, если запущен, то и не запускаем, тогда и таблица эта с флагом не нужна же, а если нужна, то заполнять ее уже из самой отрабатываемой ХП.

urvasВопрос больше в том, как избежать блокировок при аварийном завершении. Т.е. можно и без update, но тогда должен быть гарантирован строгий порядок запросов, т.е. некая очередь.
Если нужна именно очередь, возможно, вариант - в самой ХП прописать ожидание завершения предыдущего запуска.
То есть:
1. Из Джава приходит команда на постановку ХП на обработку (например, добавляет джоб)
2. Все. Все остальное - в том числе и возможность выполнения отслеживает сама ХП (а она уже не зависит от клиента и может блокировать что угодно хоть отвалится клиент, хоть нет, ей пофиг, она в джобе ))

urvasОпять всё сведется к тому, что все НЕЗАВИСИМЫЕ приложения попытаются запустить джобы, а должно отработать только одно.
Если грамотно наколхозить, то не сведется )

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

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, и чо вы прицепились к человеку зачем, да зачем, по всей видимости речь идет как раз не об олтп-операциях, а просто о запуске некой длительной обработки в контексте конкретной задачи, совсем не факт, что так будет построена вся система, даже для маленьких коротких запросов, хотя фиг знает конечно )

Petro123Job запускается под рутом.
Т.е. клиенты будут запускать под рутом.
Т.е. решение Г.
А посоны-то и не знали и чо, что под рутом? ) Пока вроде никто не умер с того.
При постановке джоба, оракле ж проверяет права доступа на запускаемые пакеты/процедуры именно пользователя.
Другое дело, что может быть задача отследить от какого именно юзера был запущен данный джоб, но это тоже не проблема ж.