Używanie sesji JPA EntityManager i Hibernate z menedżerem transakcji współdzielonych na wiosnę

Question

Mamy trudną sytuację.

1. Istnieje duży projekt, który korzysta ze specjalnych funkcji hibernacji, więc nie można zakończyć hibernacji.
2. Mamy dodać silnik procesu Activiti do projektu w trybie wbudowanym i korzystać z rozszerzeń JPA (który działa tylko z EntityManager).
3. Niektóre jednostki nie powinny być obecne w jednostce trwałej JPA, ponieważ zgodnie z dokumentacją activiti wszystkie jednostki muszą mają @Id i nie mogą używać @ IdClass/@ EmbeddedId, więc musimy wykluczyć takie jednostki z trwałej jednostki
4. Chcemy użyć jednego współdzielonego menedżera transakcji dla EntityManager i Session. Również źródła danych są identyczne (lub nawet udostępnione).
5. Wszystko jest wiosną!

Wszystkie te działania mają na celu włączenie Activiti w celu użycia EntityManager dla jego rozszerzenia JPA przy jednoczesnym zezwoleniu istniejącym kodom zależnym od hibernacji, aby kontynuować pracę.

Answer 1

Po pierwsze, twój trzeci punkt powyżej może okazać się trudny do dostosowania, jeśli chcesz mieć jedną jednostkę wytrwałości i faktycznie używasz @ IdClass/@ EmbeddedId w swoich elementach stanu hibernacji. Oto dwa możliwe rozwiązania:

1. Pull JPA do swojego projektu i skonfigurować urządzenie trwałości dla istniejących podmiotów hibernacji, ale continute delegować istniejących połączeń do hibernacji, otwierając sesję bezpośrednio. W takim przypadku twoja konfiguracja zostanie przeniesiona do JPA, ale Twój kod nie będzie. Podejście to zakłada również, że masz pewną sensowną abstrakcję wydawania obiektów sesji w sposób wtyczkowy. Zobacz this question for the crux of the solution. Jeśli masz zero elastyczności w punkcie 3 powyżej, to podejście może nie być dla Ciebie opcją.

2. Utwórz zarówno fabrykę sesji, jak i jednostkę utrwalającą oraz koordynuj transakcje przy użyciu JTA z dwoma źródłami danych XA. Mimo że dane mogą znajdować się w tej samej bazie danych, należy upewnić się, że utworzysz odrębne źródła danych w swojej konfiguracji, jeśli podejmiesz takie podejście. Zapobiegnie to dezorientacji proxy transakcyjnego Spring podczas udziału w transakcji rozproszonej. Jest to prawdopodobnie najczystsze podejście, ale niesie piętno transakcji XA, które w zależności od twojego kontenera są obecnie bardziej problemem politycznym niż technicznym.