d.nemolchevВ случае успешной вставки строки заменяем случайный ID на штатный из последовательности и на этом всё.
...когда коту делать нечего, он рэндом ID генерирует...

Migelleк заголовку параллельно добавляются подчиненные записи множеством процессов. Первый процесс создает заголовок, остальные пользуются им.
Судя по переписке, логика межпроцессного взаимодействия предполагает, что some_value суть уникальный идентификатор заголовка.
Какую пользу приносит в этой ситуации суррогат?
Похоже, что никакой.
Тогда в случае, когда новые ID появляются относительно нечасто:
1. Постройте по str или по самодельной ~детерминированной функции от него обычный индекс и объявите PK с отложенной проверкой (deferrable initially deferred), что уже предлагалось в топике.
2. Все процессы самостоятельно считают идентификатор на базе some_value согласно алгоритму п.1 и тупо накидывают дочерние записи.
3. Если при фиксации транзакции ловите exception FK - просто вставляете парента с перехватом и игнором нарушения PK.
4. Профит.

Если новые ключи генерируется постоянно - то то же самое, но deferred не делаем и вставку-игнор лепим первым шагом.

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

нет деферраблюandrey_anonymous,
Да ты просто гений проектирования пользовательских интерфейсов!


1. при чем тут вообще пользовательский интерфейс?
Пользовательский подразумевает поиск родительской записи и окошко для ее создания.
У ТС интерфейс технологический.

2. для людей без соображения воображения:

нет деферраблюКоммит в серверной процедуре?
Где мсье видит процедуру?
Прошу не приписывать мне собственных измышлизмов.

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

Итого:
1. мсье для начала неверно определил технологическую задачу как "пользовательский интерфейс", чем продемонстрировал ограниченность собственного кругозора.

2. потом измыслил
авторКоммит в серверной процедуре
чем продемонстрировал неумение управлять транзакцией иначе, чем в хранимом коде.

3. заявил серьезный опыт в области получения
автор"наполовину закоммиченный" бизнес-процесс

Ну и кто ты после этого?

нет деферраблюА данные в БД, по-вашему, появляются откуда?
В порядке ликбеза:
Данные появляются в БД по-разному.
Причем серьезные объемы - обычно минуя UI.
Грузятся из файлов, приходят по интеграционной шине, затаскиваются DI-системами, собираются с датчиков, генерируются на основе уже имеющихся данных.
Я понимаю, мсье ничего кроме UI не видел(а), а мир из подразделения мелкого саппорта видится как "навоз и дерьмо" (с).
Но все-таки попробуйте немножко вынырнуть из недр недосистемы, за которой подчищаете - это сильно ограничивает Ваш профессиональный опыт. И перестаньте уже разбрызгивать собственные... ммм... печали на окружающих - это не принесет ни признания, ни уважения.

И ещё. Продолжать обсуждение Ваших фобий и болезненных фантазий мне не очень не интересно.
Будет что-то по делу - велкам.

нет деферраблюА, ну если ты намерен бросать эксцепшен в лицо не одного индивидуального юзера, введшего через UI одну пачку связанных данных, а сразу выкидывать серьезный объем данных
Как я уже отметил, обсуждать Ваши болезненные фантазии мне не интересно.
Никакой объем нигде не выкидывается.
Есть как минимум один вопрос по сути представленного короткого демо, но Ваша паранойя пока даже не близко.
Не насилуйте мозг, не Ваше это.