Fórum Root.cz

Hlavní témata => Vývoj => Téma založeno: PetrK 19. 02. 2019, 22:50:36

Název: Viděli už jste někde distribuované transakce?
Přispěvatel: PetrK 19. 02. 2019, 22:50:36
Já ještě ne.

Proč se to nepoužívá, dokáže to přece krásně zjednodušit backend složený z vícero různých komponent. Můžu si s tím v podstatě backend udělat jako krásný stavový stroj. Šetří to práci, protože mezi transformaci A->B která se skládá z různých operací a volání jiným service můžu v případě neúspěchu udělat jen rollback. Pokud nemám dostribuované transakce, musím ten rollback dělat otravně ručně posloupností různých odvolávacích volání, čímž roste chybovost, čímž roste riziko nekonzistentního stavu databáze.
Název: Re:Viděli už jste někde distribuované transakce?
Přispěvatel: PetrK 19. 02. 2019, 22:57:25
Upozornění: Javascriptářům vstup zakázán. Jen Java, .NET a Cobol.
Název: Re:Viděli už jste někde distribuované transakce?
Přispěvatel: technomaniak 20. 02. 2019, 06:24:07
Jakože celou 1 transakci rozdělíš na více strojů v síti? Vždyť dobu celé transakce prodloužíš o dobu sítových spojení a jejich ověřování/kontrolu. Je to k hovnu. To je spíš lepší(výkonnější) mít více strojů které každý řeší celou transakci.

Pokud jsem tě správně pochopil je to podle mě je to blbost.
Název: Re:Viděli už jste někde distribuované transakce?
Přispěvatel: František Ryšánek 20. 02. 2019, 06:37:20
Dělám do včel. Živě si pamatuju se školy na konci 90.let tehdy módní téma distribuované databáze, a vrcholným číslem měl být právě 2-phase commit (2PC). Pokud si pamatuju, přednášeli nám o něm v obecné rovině, ne že by nám ho někdo předvedl (jak se to konfiguruje na nějakém reálném RDBMS). Ano určitě to zdržují latence. Tzn. hodí se to podle mého ve scénářích, které jsou "read mostly" = ta trocha zdržení při zápisu aplikaci nezabije a čtení rozložené mezi N uzlů výrazně zvedne průchodnost (a bude to mít také dobrou spolehlivost, pokud zároveň funguje nějaký failover v clusteru).
Název: Re:Viděli už jste někde distribuované transakce?
Přispěvatel: Pavel Stěhule 20. 02. 2019, 07:12:29
V databázovém světě se 2PC transakce používají, tam kde jsou nezbytně nutné - pokud potřebujete sesynchronizovat dva datové zdroje. Jinak se to moc nepoužívá - musí se počítat s latencemi, zvyšuje to nároky na obsluhu, relativně jednoduše lze vyrobit nesmrtelné transakce, které mohou držet zámky, a dělat další neplechu. Navíc to zvyšuje komplexitu systému. Bere se to jako nutné zlo. V 90 letech se čekalo, že vše se bude programovat skrz distribuované objekty - viz např. DCOM, CORBA nicméně moc se to neosvědčilo, ukázalo se, že přístup přes API - SOAP, REST je mnohem praktičtější.
Název: Re:Viděli už jste někde distribuované transakce?
Přispěvatel: PetrK 20. 02. 2019, 08:35:37
My si nerozumime. Napr SOAP umoznuje distributovane transakce. Jak to vypada.

Potrebujete prevezt system z nejakeho stavu A do stavu B. Napr. zpracovavate uver nejakeho zakaznika, chcete do dostat ze stavu "Novy" do stavu "Ke schvaleni". Prijde vam do komponenty pozadavek na zpracovani uveru. Abyste se dostali do stavu B, potrebujete zavolat komponenty X Y a Z. Kdyz se pri Z neco posere, napr. zakaznik neprojde credit checkem, tak v databazi ve vasi komponenty se udela rollback. Jenze to nestaci, vy musite jeste vratit zmeny v X a Y. Jenze X a Y jsou mimo vasi transakci, takze tak musi mit nejak pripravene API na vraceni zmen, ktere jste tam udelali. Kdyby to bylo pres distribuovane transakce, coz treba umoznuje Java SPring, tak se da rollbackovat i v X a Y.

Tzn. ja mam na mysli distribuovane transakce na urovni komponent, ne na urovni databazi. Databazim to muze byt uplne fuk, ty jsou jak jsou.
Název: Re:Viděli už jste někde distribuované transakce?
Přispěvatel: Santa 20. 02. 2019, 10:15:28
Databazim to muze byt uplne fuk, ty jsou jak jsou.
tvl, tak uz chapem preco niektore statne systemy u nas funguju ako funguju. Znizit DB na uroven sady tabuliek....
Název: Re:Viděli už jste někde distribuované transakce?
Přispěvatel: technomaniak 20. 02. 2019, 10:52:46
Tzn. ja mam na mysli distribuovane transakce na urovni komponent, ne na urovni databazi. Databazim to muze byt uplne fuk, ty jsou jak jsou.

Tak to jsem tě pochopil správně. Nemluvíš o distribuovaných databázích. Mluvíš o transakcích např. JTA, které by tu část kódu ve které probíhá transakce, ukončená commitem byla rozdělená na více mašin(např. aplikačních serverech).

Stále si zatím stojím, že ve většině případů by ztráta způsobená komunikací/potvrzeními mezi mašinama(aplikačními servery) bude zbytečně prodlužovat dobu celé transakce.

PS. navrhni testovací projekt, hoď ho na git a nech si ho zde zkritizovat. Takto je to příliš abstraktní.
Název: Re:Viděli už jste někde distribuované transakce?
Přispěvatel: PetrK 20. 02. 2019, 16:39:24
Tzn. ja mam na mysli distribuovane transakce na urovni komponent, ne na urovni databazi. Databazim to muze byt uplne fuk, ty jsou jak jsou.

Tak to jsem tě pochopil správně. Nemluvíš o distribuovaných databázích. Mluvíš o transakcích např. JTA, které by tu část kódu ve které probíhá transakce, ukončená commitem byla rozdělená na více mašin(např. aplikačních serverech).

Stále si zatím stojím, že ve většině případů by ztráta způsobená komunikací/potvrzeními mezi mašinama(aplikačními servery) bude zbytečně prodlužovat dobu celé transakce.

PS. navrhni testovací projekt, hoď ho na git a nech si ho zde zkritizovat. Takto je to příliš abstraktní.

Proc to bude zbytecne prodluzovat dobu cele transakce, kdyz ty ty komponenty musis stejne volat. Zavolas je tak jako tak, akorat to bude transakcni.
Název: Re:Viděli už jste někde distribuované transakce?
Přispěvatel: Ondrej Nemecek 20. 02. 2019, 17:51:05
Tzn. ja mam na mysli distribuovane transakce na urovni komponent, ne na urovni databazi. Databazim to muze byt uplne fuk, ty jsou jak jsou.

Tak to jsem tě pochopil správně. Nemluvíš o distribuovaných databázích. Mluvíš o transakcích např. JTA, které by tu část kódu ve které probíhá transakce, ukončená commitem byla rozdělená na více mašin(např. aplikačních serverech).

Stále si zatím stojím, že ve většině případů by ztráta způsobená komunikací/potvrzeními mezi mašinama(aplikačními servery) bude zbytečně prodlužovat dobu celé transakce.

PS. navrhni testovací projekt, hoď ho na git a nech si ho zde zkritizovat. Takto je to příliš abstraktní.

Proc to bude zbytecne prodluzovat dobu cele transakce, kdyz ty ty komponenty musis stejne volat. Zavolas je tak jako tak, akorat to bude transakcni.

Očividně není totiž otázka položena tak, zda to udělat transakčně nebo nikoli. Otázka míří, jak je transakčnosti dosaženo. Jinak je ale skutečně populárnější https://en.wikipedia.org/wiki/Eventual_consistency (https://en.wikipedia.org/wiki/Eventual_consistency)
Název: Re:Viděli už jste někde distribuované transakce?
Přispěvatel: PetrK 20. 02. 2019, 18:32:40
Tzn. ja mam na mysli distribuovane transakce na urovni komponent, ne na urovni databazi. Databazim to muze byt uplne fuk, ty jsou jak jsou.

Tak to jsem tě pochopil správně. Nemluvíš o distribuovaných databázích. Mluvíš o transakcích např. JTA, které by tu část kódu ve které probíhá transakce, ukončená commitem byla rozdělená na více mašin(např. aplikačních serverech).

Stále si zatím stojím, že ve většině případů by ztráta způsobená komunikací/potvrzeními mezi mašinama(aplikačními servery) bude zbytečně prodlužovat dobu celé transakce.

PS. navrhni testovací projekt, hoď ho na git a nech si ho zde zkritizovat. Takto je to příliš abstraktní.

Proc to bude zbytecne prodluzovat dobu cele transakce, kdyz ty ty komponenty musis stejne volat. Zavolas je tak jako tak, akorat to bude transakcni.

Očividně není totiž otázka položena tak, zda to udělat transakčně nebo nikoli. Otázka míří, jak je transakčnosti dosaženo. Jinak je ale skutečně populárnější https://en.wikipedia.org/wiki/Eventual_consistency (https://en.wikipedia.org/wiki/Eventual_consistency)

Jaka otazka tak miri, moje urcite ne. Ja mam predstavu jak je transakcnosti dosazeno, proste je vystaven v pozadi nejaky trigger na commit a rollback. Proste client zavola API treba pres SOAP, provedou se operace nad databazi, ale nic se necommituje, transakce je porad otevrena. Pokud je v procesu u CLienta vyhozena Exception, automaticky se zavola na API rollback.

Z te Eventual Consistency nejsem moc chytry.
Název: Re:Viděli už jste někde distribuované transakce?
Přispěvatel: Zdenek Henek 20. 02. 2019, 18:59:13
Pouziva se to.

V jave treba Atomikos pro Tomcat, kazdy velky java EE server jako Weblogic to ma naimplementovany. Je to jeden z hlavnich duvodu, proc v nekterych projektech pouzijeme Weblogic misto Tomcatu. Vytvarim framework, ktery je "obojzivelny". Pokud mate penize, tak Weblogic vam to naimplementuje. V Tomcatu jsem se snazil pouzit treba Bitronix nebo uz zminovany Atomikos, JBoss Transaction manager by mel jit pouzit v Tomcatu taky, ale moc uspesny jsem nebyl. Nejsem si treba jisty co s tim udela Oracle RAC :), tam radeji jen Weblogic.

Pokud mate vic databazi/ databazovych schemat, kdo kterych musite zapisovat, nebo kombinace databaze a posilani zprav treba pres JMS tak vam nic jineho nezbyva, jinak se muze stat, ze jednotlive databaze / systemy za message brokerem nebudou fungovat korektne.

S implementaci je docela problem, je to docela pomale, ale casto je te konzistence proste potreba.

V posledni dobe jsem narazil i na postup SAGA, popsane treba tady https://www.youtube.com/embed/URgDZ6NCEtY

Uplny holy grail v teto oblasti je transakcni pamet, ale na to si asi budeme muset jeste chvili pockat :)
Název: Re:Viděli už jste někde distribuované transakce?
Přispěvatel: Kamil Podlešák 20. 02. 2019, 18:59:45
Databazim to muze byt uplne fuk, ty jsou jak jsou.
tvl, tak uz chapem preco niektore statne systemy u nas funguju ako funguju. Znizit DB na uroven sady tabuliek....
Ne, DB to samozřejmě nemůže být fuk - musí se použít API pro dvoufázový commit (a DB engine musí takové API mít, samozřejmě).

Typické použití je, že se transakce provádí na dvou (třech, i více) databázích současně - přičemž se jedná o různé db ale třeba i různé db engine a i nějaký ne-db systém (typicky MQ). Takže třeba DB2+postgresql+IBM MQ.

Ano, viděl jsem to (tedy konkrétně kombinace DB2+IBMMQ+WebSphere a DB2+Postgresql+ActiveMQ+JBoss/WildFly). Je to pěkná věcička pro programátory, ale naprostá noční můra pro administrátory.
Název: Re:Viděli už jste někde distribuované transakce?
Přispěvatel: PetrK 21. 02. 2019, 07:49:22
S implementaci je docela problem, je to docela pomale, ale casto je te konzistence proste potreba.

Me prijde ze te konzistence je potreba snad vzdy u nejakeho korporatniho backendu. To ze se na to kasle a misto toho se povola armada opravaru dat v databazi je vec druha. Ja jsem takovy projekt jednou mel. Ustavicne pokazena data v DB, spolu se srasenym kodem to bylo naprosto otresne, objevovaly se chyby, kde nikdo nevedel co je pricin,a jestli je to bug v kodu, nebo je to zpusobeno nedokonalym "db machine" strojem. Ustavicne se vyrabely skripty na opravu dat v DB.

To je proste jako hodinky a vsechno do sebe musi zapadat.

Proto me fascinuje, ze se nekoupi poradny HW pro DB a nedelaji se distribuovane transakce, aby byly databazova schemata konzistentni nejen sama, ale i navzajem vuci sobe.
Název: Re:Viděli už jste někde distribuované transakce?
Přispěvatel: František Ryšánek 21. 02. 2019, 08:21:52
Zkusil jsem zagooglit Distributed Transaction Manager (https://www.google.com/search?q=information+technology+"distributed+transaction+manager"). Protože to možná kdysi bejvalo k dispozici i jako "nezávislá služba".

Jedno zajímavé video (https://www.youtube.com/watch?v=YPbGW3Fnmbc) z novější doby - neméně zajímavé jsou komentáře pod videem :-)
Název: Re:Viděli už jste někde distribuované transakce?
Přispěvatel: Zdenek Henek 21. 02. 2019, 08:56:36
Ano je potřeba vždy, ale ne vždy musí transakce využívat víc než jen jedno databázové spojení a ne vždy musí být fatální, když se použijí dvě databázová spojení.

Máme teď systém, kde to přesně takto funguje. Data jsou v jednom schematu a používají vlastní jdbc pool, až dojde k importu dat, tak se vytvoří metada používají jiné schema a jiny jdbc pool, pokud něco hodí vyjímku při vytváření metadat, tak při volání rollback se odstraní i data, ale je to na úrovni aplikace ne na úrovni transaction manageru. Důvod je i ten, že import dat může být velký a trvat výrazně déle, než je timeout globální transakce a může to být hodně dat. 2PC bych doporučil omezit na změnu pár záznamů.

Osobně bych se dnes spíš zajímal o koncept SAGA a 2PC bych dal přednost až když by mi SAGA nefungovala.
S 2PC jsme meli veselo u Oracle 10g, pro update indexu prostorovych dat se používala globální temp tabulka, 2PC to občas položilo, nevíme proč a zač. Oracle nikdy chybu nepřiznal, asi už opraveno. Pro ten projekt pozdě ...


S implementaci je docela problem, je to docela pomale, ale casto je te konzistence proste potreba.

Me prijde ze te konzistence je potreba snad vzdy u nejakeho korporatniho backendu. To ze se na to kasle a misto toho se povola armada opravaru dat v databazi je vec druha. Ja jsem takovy projekt jednou mel. Ustavicne pokazena data v DB, spolu se srasenym kodem to bylo naprosto otresne, objevovaly se chyby, kde nikdo nevedel co je pricin,a jestli je to bug v kodu, nebo je to zpusobeno nedokonalym "db machine" strojem. Ustavicne se vyrabely skripty na opravu dat v DB.

To je proste jako hodinky a vsechno do sebe musi zapadat.

Proto me fascinuje, ze se nekoupi poradny HW pro DB a nedelaji se distribuovane transakce, aby byly databazova schemata konzistentni nejen sama, ale i navzajem vuci sobe.
Název: Re:Viděli už jste někde distribuované transakce?
Přispěvatel: Zdenek Henek 21. 02. 2019, 08:58:39
Ano je potřeba vždy, ale ne vždy musí transakce využívat víc než jen jedno databázové spojení a ne vždy musí být fatální, když se použijí dvě databázová spojení.


Když nad tím teď přemýšlím, tak jsme si vlastně naimplementovali takové poloviční 2PC :), ale v tomto případě jsme si to mohli dovolit, protože je celý systém pod naší kontrolou.
Název: Re:Viděli už jste někde distribuované transakce?
Přispěvatel: _mbily 21. 02. 2019, 10:25:06
Distribuované transakce jsou staré téměř jako lidstvo samo  :). Distribuovaný transakční manager existoval už před více než čtvrt stoletím. Akorát že byl určen pro velké kluky na (tehdy) velkých strojích. Letmo jsem vygooglil jeden paper věnující se výkonu jednoho takového DTM: https://www.computer.org/csdl/proceedings/reldis/1992/2890/00/00235145.pdf
Název: Re:Viděli už jste někde distribuované transakce?
Přispěvatel: Ivan Brezina 21. 02. 2019, 16:59:00
Ono to zacina jednoduse, staci zakliknout nejaky checkbox ve Weblogicu anebo nakonfigurovat DataSource podle navodu na internetu. Pak se to zacne komplikovat, alespon na Oracle. Dokumentace je fura, ale zadna kniha se nevenuje pouze teto problematice. 2PC se objevuje jen jako zakerna poznamka pod carou v nejake jine dokumentaci. A pak vznikaji temata jako Advanced Queueing vs. 2PC, RAC vs. 2PC, JDBC vs 2PC, Application continuity vs. 2PC.
Pak se zjisti, ze in doubt transaction muze drzet zamek dele nez se cekalo a ze je to potreba resit. A nakonec se objevi bugy a zjisti se, ze ne vse funguje podle dokumentace. Navic k probemum dochazi zridka, nedaji se reprodukovat, ...
Název: Re:Viděli už jste někde distribuované transakce?
Přispěvatel: Ondrej Nemecek 21. 02. 2019, 20:26:59
Citace
Citace
Očividně není totiž otázka položena tak, zda to udělat transakčně nebo nikoli. Otázka míří, jak je transakčnosti dosaženo. Jinak je ale skutečně populárnější https://en.wikipedia.org/wiki/Eventual_consistency (https://en.wikipedia.org/wiki/Eventual_consistency)

...

Z te Eventual Consistency nejsem moc chytry.

Eventual Consistency = pokud jsem to pochopil tak „nakonec dotečou správná data do všech uzlů“