Anketa

Jaká je vaše backendová platforma?

Java
11 (47.8%)
.NET
1 (4.3%)
Python
7 (30.4%)
Cobol a jiné.
3 (13%)
Nedelam backend.
1 (4.3%)

Celkem hlasů: 20

Viděli už jste někde distribuované transakce?

Re:Viděli už jste někde distribuované transakce?
« Odpověď #15 kdy: 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.


Re:Viděli už jste někde distribuované transakce?
« Odpověď #16 kdy: 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.

Re:Viděli už jste někde distribuované transakce?
« Odpověď #17 kdy: 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

Re:Viděli už jste někde distribuované transakce?
« Odpověď #18 kdy: 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, ...

Re:Viděli už jste někde distribuované transakce?
« Odpověď #19 kdy: 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

...

Z te Eventual Consistency nejsem moc chytry.

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