Najlepiej (imho) jakbyś na początek zrozumiał, że architektura której najpewniej używasz, powodująca wymieszanie logiki z warstwą persystencji, ssie strasznie mocno (że aż nieprzyjemnie) i byś to odseparował (np. w duchu portów i adapterów).
Mając wydzieloną logikę biznesową i zamodelowany seans wraz z siedzeniami problemy z adnotacjami jpa nagle znikają i życie staje się przyjemniejsze.
Na poziomie db jako takim też w sumie nie potrzebujesz mieć żadnych takich relacji, alternatywnie możesz się posługiwać gołymi identyfikatorami zamiast w encjach zagnieżdżać kolekcję.
Te ficzery że encja bazodanowa z powiązanymi kolekcjami gdzie zarządza wszystkim hibernate i nie musisz nawet wołać save były fajne w czasach architektur warstwowych (a przynajmniej wtedy uważano, że to jest fajne). Aktualnie im ta warstwa persystencji jest cieńsza, implementowana możliwie najpóźniej jak się da i w pełni zastępowalna przez alternatywne implementacje (np. na bazie hash mapy w pamięci) tym lepiej dla Ciebie i dla biznesu.
Zrób kilka kroków wstecz, poczytaj co to jest cloudy think i zastanów się jeszcze raz nad sposobem w którym piszesz kod bo sam sobie tworzysz problemy.