Witajcie,
Ostatnio wgryzłem się w temat nowego Springa w wersji 5.0. Zaciekawił mnie bardzo temat Fluxów i zarządzania transakcjami przy nich.
Z tego co wiem, to każdy np. map w takim fluxie wykonywany jest asynchronicznie. Co jeżeli w takim mapie operujemy na bazie? Jak wtedy zarządzać transakcją?
Pozdrawiam
Wbrew temu co mogłeś zobaczyć w Springu / JavaEE - transakcjami w SQL zarządza sie przez begin, commit i rollback :-)
To plus promisy i jakiś executor (no bo niestety JDBC jest blokujące) pozwala robić normalnie operacje na SQLowych bazach danych.
Są tez wynalazki typu: https://github.com/davidmoten/rxjava-jdbc ale nie używam.
Btw no i dla pewności najlepiej nie używaj JPA z reactorem ani rxjava - bo to się może skończyć nawet gorzej niż używanie JPA w Springu albo JavaEE :-)
A czym niby złym kończy się korzystanie z JPA w Springu?
@scibi92: Wydaje mi się, że JPA/Hibernate jest pomyłką bo:
Może rzeczywiście zarządzanie transakcją przez jakiś JDBC template jest bezpieczniejsze w takim środowisku. Jakie jest zalecane persistence dla projektu reaktor?
No cóż ja się nie zgodzę. Trzeba umieć i to i to i niezaleznie czy się korzysta z ORM czy nie. To co mnie w JPA irytuje to Criteria API, uważam że dawne Hibernetowe Criteria było lepsze ;)
Dla reactora i wszystkiego tego typu najlepsze sa bazy typu Cassandra, Mongo etc. (czyli te które mają async api) i nie maja problemu z transakcjami w stylu SQL.
A JPA jest kujowe bo łamie troszkę obiektowość. Na przykład o jakim interfejsie czy enkapsulacji można mówić jak obiekt o danym typie może być detached, managed i trzeba prześledzić skąd przyszedł żeby się dowiedzieć jak się zachowa. Bo raz pewne metody zadziałają, raz nie....
Może powinny być prefixy w nazwach j:
Person detachechWithAccountsAndPolicietsFetchedCustomer....
albo
Person possiblyDirtyStateJPAUser;
Ogólnie dużo ludzi ORMy generalnie hejtuje : http://blogs.tedneward.com/post/the-vietnam-of-computer-science/
Cóż w moim przypadku ja nie mam takich problemów z detached itd. dzięki odpowiedniej architekturze :)
Załóżmy ze użyje cassandry jak powiedział @jarekr000000. Jak wtedy wyglada zarządzanie transakcjami? Kiedy zaczynam transakcje, kiedy ja commituje? Jak zrobię locka na główny obiekt np. usera, to wtedy wszystkie obiekty pokrewne w drzewie sa zablokowane?
W Cassandrze nie ma transakcji. Dziękuje do widzenia :)
Jakbyście chcieli zobaczyć jak to wygląda w Cassandrze bez transakcji, itp. to w poniedziałek w Warszawie na festiwalu 4developers będę miał wykład o Lagomie (i tam
będzie Cassandra i CQRS).
http://2017.4developers.org.pl/en/program/lectures/lagom-no-nareszcie/
Generalnie przy robieniu aplikacji WEB ( i nie tylko) gdzie dostępności, responsywność i odporność na awarie jest ważniejsza niż globalna spójność.
Na przykład w banku pewnie się przyzwyczaiłeś, że jak zapłacisz kartą debetową, albo z bankomatu to na koncie możesz je jeszcze przez dzień widzieć. Dopiero następnego dnia wchodzisz na konto i przychodzi rozczarowanie - jednak kasa zeszła. Trochę upierdliwe ale da się z tym żyć.
Ale bardzo się wkurzasz jeśli zamierzasz kupić właśnie 4 browary, i chcesz zapłacić kartą, a tu nie ma połączenia z bankiem, albo trwa to 10 minut i blokujesz kasę w TESCO.
W ogólności jest takie twierdzenie CAP, które mówi, że nie możesz mieć zawsze dostępnego, odpornego na hardwarowe błędy transmisji) i spójnego (dane) systemu (dokładnie jak twierdzenie brzmi możesz sprawdzić).
Dalsze powody to czystość i weryfikowalność kodu (i tak osobiście to te 2 dla mnie są najważniejsze )
oraz efektywne wykorzystanie hardware ( minimalizacja cache miss na L1 i L2).
Spring
Shalom