@Transactional - czy działa poprawnie?

Odpowiedz Nowy wątek
2020-03-23 08:36

Rejestracja: 2 tygodnie temu

Ostatnio: 1 tydzień temu

0

Hej, jako że @Transactional nie działa na metodach wołanych z tego samego beana, to czy takie przykład będzie działał tranzakcyjnie?

    interface BaseService {
        void doWork();
    }

    class BaseServiceImpl implements BaseService {

        DataFetcher dataFetcher;

        public BaseServiceImpl(DataFetcher dataFetcher) {
            this.dataFetcher = dataFetcher;
        }

        @Override
        public void doWork() {
            dataFetcher.fetch();
        }
    }

    interface DataFetcher {
        List<String> fetch();
    }

    class DataFetcherImpl implements DataFetcher {

        public List<String> fetchItems() {
           return fetch();
        }

        @Override
        @Transactional
        public List<String> fetch() {
            //fetchowanie danych
        }
    }

Teoretycznie fetch() jest wołany z tego samego beana czyli DataFetcher, no ale fetchItems() które woła tranzakcyjne fetch() jest wołane już z innego beana BaseService.

Czy w takim wypadku jest to wywołanie tranzakcyjne i @Transactional dziala poprawnie?

edytowany 1x, ostatnio: HikaruNagasaki, 2020-03-23 08:38

Pozostało 580 znaków

2020-03-23 09:32

Rejestracja: 4 lata temu

Ostatnio: 3 minuty temu

0

Możesz sprawdzić to samemu - postaw breakpointa w metodzie fetch() i sprawdź, czy w stracktrace będzie proxy Springowe TransactionInterceptor. Ale nie zobaczysz go, ponieważ tutaj ta metoda jest bezpośrednio wołana z tej samej klasy, z metody fetchItems. Miejsce wywołania metody fetchItems nie ma znaczenia.

Pozostało 580 znaków

2020-03-23 10:00

Rejestracja: 3 lata temu

Ostatnio: 4 minuty temu

Lokalizacja: U krasnoludów - pod górą

6

Jeśli z innego beana wywołasz DataFetcherImpl.fetchItems() to @Transactional na fetch raczej nie zadziała, ale pewności nie ma (możesz mieć tzw. aspectj włączony).
Jeśli z innego beana wywołasz DataFetcherImpl.fetch() to @Transactional na fetch raczej zadziała, ale pewności nie ma (możesz mieć wiele innych rzeczy źle ustawione).


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.
edytowany 2x, ostatnio: jarekr000000, 2020-03-23 10:01

Pozostało 580 znaków

2020-03-23 10:38

Rejestracja: 6 miesięcy temu

Ostatnio: 11 godzin temu

0

A nie będzie tu miało jeszcze przypadkiem znaczenia jak dany bean zostanie utworzony? Tzn springowo (@Repository/@Component/coś tam jeszcze) czy "tradycyjnie" (jawnie new). W szczególności jak to będzie wyglądało gdy składamy sobie @Bean'y ręcznie w @Configuration.

Pozostało 580 znaków

2020-03-23 11:04

Rejestracja: 2 tygodnie temu

Ostatnio: 1 tydzień temu

0
jarekr000000 napisał(a):

Jeśli z innego beana wywołasz DataFetcherImpl.fetchItems() to @Transactional na fetch raczej nie zadziała, ale pewności nie ma (możesz mieć tzw. aspectj włączony).
Jeśli z innego beana wywołasz DataFetcherImpl.fetch() to @Transactional na fetch raczej zadziała, ale pewności nie ma (możesz mieć wiele innych rzeczy źle ustawione).

Dzięki za rozjaśnienie, a co w przypadku jeśli:

Jeśli z innego beana który już działa w transakcji wywołam DataFetcherImpl.fetchItems() to czy @Transactional na fetch będzie transakcyjnie wykonane? Tj. "podpięty" pod @Transactional z innego beana

Pozostało 580 znaków

2020-03-23 11:16

Rejestracja: 12 lat temu

Ostatnio: 1 godzina temu

0

Tak, jeśli metoda zostanie wywołana na proxy Springowym. Jeśli wołasz na innym beanie, który został wstrzyknięty przez Springa, to na 99% zadziała. Polecam czytanie dokumentacji.


Ivory Tower Architect
edytowany 1x, ostatnio: Charles_Ray, 2020-03-23 11:16
Pokaż pozostałe 14 komentarzy
Widzę różnice, ale nie na poziomie konfiguracji puli połączeń :) Odnośnie samych aspektów - mamy testy integracyjne, mamy monitoring i metryki. Nie popadajmy w paranoję. Jaka jest szansa, że testy przechodzą, a na produkcji dane się nie zapisują? 1/1000? - Charles_Ray 2020-03-24 17:41
To nie tak prosto, że pula połączeń wszystko rozwiąże możesz mieć w aplikacji i to w jednym flow transakcje readonly, a nawet autocommita zamierzonego :-) I problem nie jest, że dane się nie zapiszą tylko, że siezapiszą. Problem wzrasta z ilością członków zespołu i czasu - po prostu w pewnym momencie po heisenbugu na produkcji wychodzi, że nikt w zespole nie umie springa, a błędy są nie do odkręcenia (bo częśc systemu chodzi tylko dzięki błedom w kodzie...) - jarekr000000 2020-03-24 19:40
Genearlnie największy problem : znaleźć kogoś kto zna springa, bo znam tony ludzi, którzy stale w springu programują, niektórzy od wersji 1.x, ale żeby ktoś ogarniał choćby zasady ... to jest już krucho. Po prostu jak jest problem to ludzie wrzucają 10 losowych adnotacji aż zadziała... i czasem zadziała. - jarekr000000 2020-03-24 19:41
Po prostu jak jest problem to ludzie wrzucają 10 losowych adnotacji aż zadziała... i czasem zadziała. wydaje mi się, że można to odnieść do każdej technologii :) problem ludzki - Charles_Ray 2020-03-24 21:08
Kwestia tego w ile potem miejsc musisz zaglądnąć, przetestować i przedebugować, aby sprawdzić czy kawałek kodu jest poprawny. - jarekr000000 2020-03-24 22:26

Pozostało 580 znaków

2020-03-24 21:23

Rejestracja: 1 rok temu

Ostatnio: 2 minuty temu

0

Tak na marginesie wątku, już poza Springiem.

Czasem sobie przetestuję to i owo z EE "krzyżowo" na TomEE i Payarra.
Znaczna większość rzeczy chodzi jednakowo.
Tematy @ Transactional / JTA są z całego EE najbardziej przej...ne 1) Uciekam jak diabeł od święconej wody.

<small>1) oprócz ewentualnej zagubionej sesji JPA w sesji webowej.</small>

UPDATE: znalazłem

edytowany 4x, ostatnio: AnyKtokolwiek, 2020-03-25 23:22

Pozostało 580 znaków

Odpowiedz

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0