Projectreactor, Spring 5.0 i transakcje

0

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

0

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 :-)

0

A czym niby złym kończy się korzystanie z JPA w Springu?

0

@scibi92: Wydaje mi się, że JPA/Hibernate jest pomyłką bo:

  • jak ktoś dobrze czuje się w obiektach to i tak woli użyć bazy bazującej na kolekcjach
  • jak ktoś się dobrze czuje w bazach to woli mieć pełną kontrolę nad SQL
  • w JPA trzeba znać się na 1 i 2 i do tego ogarniać brzydką specyfikację: jak mam pisać w JPA to tylko dlatego, że ktoś mi kazał
  • ponieważ lubię bazy w JPA raczej myślę o tym co chcę aby mi wygenerował ORM (to tak jakbym używał złego narzędzia do problemu) i jak to zapisać z użyciem @OneToMany itp.
  • ze względu na rynek pracy trzeba znać JPA, niestety

Może rzeczywiście zarządzanie transakcją przez jakiś JDBC template jest bezpieczniejsze w takim środowisku. Jakie jest zalecane persistence dla projektu reaktor?

0

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 ;)

2

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/

0

Cóż w moim przypadku ja nie mam takich problemów z detached itd. dzięki odpowiedniej architekturze :)

0

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?

0

W Cassandrze nie ma transakcji. Dziękuje do widzenia :)

0

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/

0

A powiedzcie do czego warto to wszystko to wykorzystac? jakie use casy ?

0

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).

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