andreykaTа можно ли как то в рамках спринга передать какой-то этакий объект который как футура будет стоять до тех пор пока результат внутри него не появится?

Опять городите черт пойми что. Если уж вы используете асинхронность, то subscriber and observer по идее должны быть полностью decoupled, в этом весь смысл. Именно чтобы избежать многопоточных багов, обычно это реализуется поверх системы мессаджинга на основе иммьютабл сообщений. Ну и асинхронность подразумевает как раз таки, что второй процесс запустится ПОСЛЕ того как данные для него готовы(в колбэке), а не будет их ждать такая архитектура называется другим словом

У вас JVM одна? Вы не думайте в рамках фреймворка\энвайрнмента, а сначала подумайте как вашу проблему можно решить концептуально правильно в архитектурном плане, а потом уже реализовывайте свое решение.

А то вы пытаетесь что-то там выкрутить ограничваясь контекстами спринга, хибера и всякого непонятного аоп.

И поясните момент, так все это в рамках одного приложения(монолита)? Или приложения разные? Если монолит, то чем вас не устраивает обычный тредпул + Future?

maytonandreykaTпропущено...

грубо очень грубо созадется некий набор атрибутов для сферической задачи в вакууме и в джобу передается айдишка этого набора атрибутов, по которым потом порождается целый мешок действий и в базе появляется еще мешок сущностей. нет не тривиальный )) все тривиальные я уже пофиксил ))
Ну... если вспомнить что есть такая SQL-ная практика что PK никогда не меняются. Тоесть если ты куда-то
передаешь PK и у тебя ACID то все будет чики-пики

Я тоже никак не пойму, почему не взять да закоммитить?

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