andreykaTКакой подход лучше тут использовать?

Скорее всего вы неправильно решаете задачу, но я не стану вас уговаривать :)

В вашем случае если сущность рид-онли,то можно использовать кэш второго уровня, по-моему он потокобезопасен. Если же вы вытянули сущность в одном потоке, поменяли ее и передав в другой поток хотите работать с измененной версией - то могу вам только пожелать удачи.

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


Это все замечательно, но к первоначальному вопросу отношения мягко говоря не имеет. Ну и городить пулы тоже не надо, когда есть стандартные проверенные временем брокеры сообщений

andreykaTзабыл никпропущено...


Скорее всего вы неправильно решаете задачу, но я не стану вас уговаривать :)

В вашем случае если сущность рид-онли,то можно использовать кэш второго уровня, по-моему он потокобезопасен. Если же вы вытянули сущность в одном потоке, поменяли ее и передав в другой поток хотите работать с измененной версией - то могу вам только пожелать удачи.
да все спорные места я перевел на копии объектов. осталось только одно. ))
на самом деле, проблема в том, что сущность создается, и вроде как сохраняется (репо возвращает айди сущности), эта айдишка передается в параллельный поток, а поток читая эту сущность из репо получает налл )) т.е. в базе сущности вроде как НЕТ )))

решения с наскока вижу здесь два: передавать айди сущности после закрытия сессии -- работает. и в параллельном потоке каким-то образом ПОДОЖДАТЬ появления этой сущности в базе

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

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

Petro123andreykaTПОДОЖДАТЬ появления этой сущности в базе
если производительность устраивает, то в сущность завести флаг ОчереднойШагОбработки.
Потом один поток создаёт и сохраняет.
Второй поток периодически сканирует базу и делает второй шаг обработки.

Да все что угодно, главное не сессии хиберовские шарить Вплоть до сериализации энтити в json какой-нить и шлем в мессадж брокер, делов то. Ну это если транзакции не важны

andreykaTтранзакции в данном контексте не важны. ну в общем. всё верно в моем подходе - слать копии объектов. осталось придумать как сделать в одно движение копию хиберской сущности. хибернейтутилз.копипропертиз не предлагать )) сериализовать в джейсон - тоже не очень удачный вариант (в моем конкретном случае разумеется)

Что там за сущность такая? Вариантов сериализации море, начиная от ручного Externalizable заканчивая Dozer

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

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

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

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

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

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

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

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

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