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

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

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

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

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

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