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

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

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

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


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

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


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

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

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

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

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

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

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

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

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