Spring boot OSIV

Cześć,
czy macie doświadczenie produkcyjne z ficzerem Springa OSIV(Open Session In View) ?
Okazuje się że Spring boot od wersji 2.0 ma ten ficzer włączony by default. Wyczytałem ostatnio, że jest to anty pattern i może mieć negatywny wpływ na wydajność i skalowanie aplikacji na produkcji. Czy macie jakieś doświadczenia produkcyjne w tym zakresie, jest się czego obawiać?
Zastanawiam się czy wyłączyć ten mechanizm i nie używać lazy loading (jestem jeszcze przed wdrożeniem na proda), czy czekać aż na prodzie rzeczywiście pojawią sie jakieś problemy.

Maciej

That's a name I haven't heard in a long long time..., zresztą to w ogóle ma jakiś sens dzisiaj kiedy nikt nie uzywa server-side-templates? Chyba średnio ;)
Tego to się używało 10-15 lat temu, jak nie było zaawansowanych narzędzi frontendowych do budowania SPA i przeładowywania danych na stronie przez ajaxowe requesty.

Sugeruje nie używać w ogole JPA i wtedy problem lazy loadingu nie występuje. Nie warto dzielnie walczyć z problemami nie znanymi w innych technologiach.

Pattern / pseudo pattern / antypattern Session in View to nie było coś, co istniało tylko w Springu. Wzorzec bywał w web-apkach zupełnie a-sprngowych (a wszystko w zamierzchłych czasach)

Niby miało ratować JPA lazy loading, ale przenosiło problemy gdzie indziej. Nie spotkałem się nigdy z tym skrótem, gdy nie było mowy o JPA.

Powtórzę wyraźnie za Shalomem, @p_maciek jakiego View, jakiej technologii używasz w projecie? Bo zależnie od odpowiedzi to jest od nie-rekomendowane po zagadnienie-które-dla ciebie-nie istnieje

Ja w pytaniu o Spring Boota widzę dodatkową mentalną zależność głowy od w/w produktu. Tu TYLKO udogodnienia (czasami wątpliwe) do startu dodatkowych modułów, nie powinno wpływać na wizję projektową

p_maciek napisał(a):

Cześć,

czy macie doświadczenie produkcyjne z ficzerem Springa OSIV(Open Session In View) ?
...
wyczytałem ostatnio, że jest to anty pattern i może mieć negatywny wpływ na wydajność i skalowanie aplikacji na produkcji.

Ma negatywny wpływ już na samo myślenie projektowe, np betonować prowizorkę w postaci nieprzemyślanego lazy

Nie musi zabijać wydajności bardziej niż JPA, SQL i same relacyjne czyli słabo się rozpraszające bazy danych, i nadwaga samego Springa + Boota
U mnie nigdy nie było kilerem wydajności, ale ślepą uliczką projektową zdecydowanie tak

@AnyKtokolwiek: Nie użuwam View, to tylko czysto backendowa apka spring boot + hibernate. Zauważyłem użycie lazy loadingu poza transakcjami i tak analizując dlaczego to w ogóle działa odkryłem ten OSIV. No ale wygląda, że problem jest w niepoprawnym użyciu lazy laodingu, który OSIV tylko ukrywa. Dobrze myślę ?

Przecież lazy loading zabija wydajność kompletnie. Jak już musisz korzystać z JPA [minuta ciszy *] to skorzystaj z narzędzi które umożliwią załadowanie wszystkich potrzebnych danych takich jak fetch join.
Pomijając to że warstwa frontu nie powinna mieć w ogóle świadomości że korzystasz z JPA!

A propos Lazy ... nie umiem sobie wyobrazić problemów lazy w usłudze serwera REST. Pyk i już wszystko zserialzowane do JSON-a, nie ma żadnego "dalszego ciągu"...

Chyba, ze wyobraźnia mi szwankuje

@AnyKtokolwiek: no to cyk: wyobraź sobie że:

1. Wszystko masz ustawione na lazy
2. Wyciągasz sobie coś z repozytorium
3. Teraz próbujesz przerobić to coś na DTO które twoja aplikacja ma wypluć, zrobić jakieś wyliczenia, cokolwiek. W trakcie tych operacji potrzebujesz danych które nie zostały załadowane bo są "lazy", więc lecą sobie n+1 selecty żeby dociągnąć czego brakuje
4. Brak profitu

Oczywiście to nie jest ten starożytny przykład in view, ale problem złego użycia lazy nadal występuje.

Jakby ktoś chciał poczytać to tu jest długa dyskusja dlaczego OSIV jest włączone by default :
https://github.com/spring-projects/spring-boot/issues/7107

W skrócie łatwość użycia i produktywność developerów przeważyła nad dobrym designem i nie propagowaniem złych nawyków, Ciekawe.

p_maciek napisał(a):

W skrócie łatwość użycia i produktywność developerów przeważyła nad dobrym designem i nie propagowaniem złych nawyków, Ciekawe.

XD

Jakby mogli to by jeszcze kontrolę typów wyłączyli :D

@Aleksander32: > Przecież lazy loading zabija wydajność kompletnie.

Problem w tym, że Eager loading też zabija wydajność :-)
Jak żyć?
(tak naprawdę problem dotyczy ORMów - więc są dwa oczywiste rozwiązania)

Problem w tym, że Eager loading też zabija wydajność :-)

@jarekr000000 no tak i nie. Tzn jeśli rzeczywiście załadujesz całą encje np. klienta ze wszystkimi zamówieniami, adresam itp to rzeczywiście. Ale jak robisz selecta to możesz wybrać co chcesz zainicjować w trakcie zapytania np. poprzez fetch join i jak na to że musisz korzystać z JPA jest OK.