Podczas gdy wiele postów zostało napisanych na temat OpenSession / EntityManagerInViewFilter Springa, nie mogłem znaleźć żadnego, który wspomniałby o jego wadach. Z tego, co rozumiem, i zakładając typową architekturę warstwowej aplikacji internetowej wykorzystującej warstwę usługi @Transactional, filtr działa w następujący sposób:

Filtr przechwytuje żądanie serwletuFiltr otwiera EntityManager i wiąże go z bieżącym wątkiemNazywany jest kontroler internetowyUsługa połączeń kontrolera sieci WebPrzechwytywacz transakcji rozpoczyna nową transakcję, pobiera związany z wątkiem menedżer EntityManager i wiąże go z transakcjąUsługa jest wywoływana, robi pewne rzeczy z EntityManager, a następnie wracaPrzechwytywacz transakcji opróżnia EntityManager, a następnie zatwierdza transakcjęKontroler sieciowy przygotowuje widok, a następnie powracaWidok jest zbudowanyFiltr zamyka EntityManager i odłącza go od bieżącego wątku

W krokach 8 i 9 obiekty ładowane przez EntityManager wątku są nadal zarządzane. W konsekwencji, jeśli w tych krokach zostaną dotknięte leniwe skojarzenia, zostaną one załadowane z bazy danych przy użyciu wciąż otwartego EntityManager. Z tego, co rozumiem, każdy taki dostęp będzie wymagał, aby baza danych otworzyła transakcję. Zarządzanie transakcjami Springa nie będzie tego świadome, stąd nazywam to „transakcją ukrytą”.

Widzę 2 problemy z tym:

Załadowanie kilku leniwych skojarzeń spowoduje wiele transakcji bazy danych, co może być trafieniem dla wydajnościObiekt główny i jego leniwe skojarzenia są ładowane w różnych transakcjach bazy danych, więc dane mogą być nieaktualne (np. Root ładowany przez wątek 1, stowarzyszenia root aktualizowane przez wątek 2, skojarzenia root ładowane przez wątek 1)

Z jednej strony te dwa problemy wydają się wystarczające, aby odrzucić ten filtr (uderzenie wydajności, niespójność danych). Z drugiej strony rozwiązanie to jest bardzo wygodne, unika pisania kilku linii kodu, problem 1 może nie być tak zauważalny, a problem 2 może być czystą paranoją.

Co myślisz?

Dzięki!