Cześć
Mam w CDI wstrzykniętego entity managera i w chwili kiedy robię find zaciąga mi lazy listę.
I tu mam pytanie czy provider zaciąga to zachłannie czy jest w CDI tworzona jakaś transakcja, ale to dopiero chyba od JEE7.
Osobiście skłania się do tego że idzie to zachłannie, ale wolę zapytać się kogoś bardziej doświadczonego.
Dzięki za odpowiedź.
Zachłanna lazy lista? Coś nie pasi.
Lazy jest sugestią dla providera, może ładować lazy ale nie musi.
@Koziołek @Shalom?
Ale gdzie ty to wstrzykujesz? Bo jak do jakiegoś EJB to domyślnie działa tam container managed persistence i transakcja jest odpalana z automatu. Jakaś transakcja musi tam działać bo inaczej nic byś z bazy nie pobrał.
Niemniej jak coś jest lazy to będzie lazy.
Do CDI, EntityManagera wstrzykuję do @RequestScoped i tam potem robię em.find
To ciekawe bo spodziewałbym się w takiej sytuacji jakiegoś transaction required excetpion. A czy czasem nie wołasz metody z tego beana z poziomu czegoś co otwiera transakcje? Bo wtedy transakcja jest propagowana w dół i twój bean działa w obszarze transakcji otwartej wyżej (np. przez jakieś EJB które wywołało metodę). To by też rozwiązywało zagadkę "lazy ale nie lazy" bo póki jesteś w obszarze transakcji to właściwości lazy będą dociągane w miare potrzeby. Włącz logowanie zapytań w JPA i powinieneś wtedy zobaczyć że lecą dodatkowe selecty kiedy odnosisz się do tych składników lazy (klasyczny błąd n+1 selectów ;])
Dzięki @Shalom, tego potrzebowałem. Ten CDI jest wołany z stateless WS i rozumiem, że transakcja jest wtedy propagowana w dół nawet z EJB na CDI?
Musiałem nie doczytać, albo zapomnieć, dzięki. A się kurcze zastanawiałem czemu to działa :P
Jak widać domyślnie transakcja jest propagowana w dół o ile nie zdefiniujesz inaczej. Sugeowałbym jednak zrobic fetch join na tych własnościach lazy skoro są ci potrzebne, żebyś niepotrzebnie nie zabijał sobie bazy dodatkowymi selectami.
Btw, ta najprostsza wersja metody find nie wymaga wywołania w transakcji, najwyżej stworzy sobie tymczasową i zwróci encje zdetaczowane.