Ano, jeste jednou diky za reakce. Shrnul bych, jakou cestou bych se vydal: Odesilatel potrebuje provest 2 zapisy do 2 databazi, vytvori 2 zpravy, ktere zabali do jedne obalovaci a tu posle do urciteho JMS cile. Z toho tuto zpravu obsahujici dve zpravy precte TBS (transaction broker service), zpravy "vybali" a zahaji transakci - odesle obe zpravy k vyrizeni (napriklad a: pridej zakaznika, b: vytvor fakturu), bude dohodnuty protokol, kdy oba prijimaci systemy nejprve poslou ready-for-commit, pote dostanou prikaz od TBS ke kommitu a ten jeste potvrdi. Nakonec TBS posle zpravu odesilateli, ze bylo vsechno vyrizeno.
2007/11/27, Patrik Beno <[EMAIL PROTECTED]>: > On Nov 27, 2007 1:12 PM, Lukas Zapletal <[EMAIL PROTECTED]> wrote: > > Ano, jeste mozna snad doplnim, ze mnohe implementace pridavaji podporu > > XA transakci, coz v podstate znamena, ze JMS zprava muze byt soucasti > > nejake distribuovane transakce. Co ovsem potrebuji je nad JMS vytvorit > > nejaky Transaction Broker, ktery to bude resit. Ze bude JMS nastrojem > > pro TB uz je vec jina, myslim si, ze to neni zadne neprirozene > > zneuziti. Nektere messagingove systemy dokonce nabizeji prostredky pro > > notifikace, synchronni potvrzovani a podobne. > > ano, ale XA len na jednej strane, cize (1) poslem spravu a (2) poznacim si > do databazy, ze som ju poslal; nasleduje XA commit, ktory zaruci, ze > (a) sprava je odoslana a zaznam v DB zapisany, > alebo > (b) ani jedno, ani druhe :-) > > o doruceni sa tam nic nehovori, ani nemoze. > > Napriklad, nemozete chciet potvrdenku o doruceni spracovat v tej istej XA > transakcii, pretoze k doruceniu nemoze dost, kym nespravite uspesne commit > :-) > > A z toho vyplyva, ze pokial by ste chceli (napriklad) synchronizovane > dorucenky, odosielatel spravy musi byt netransakcny (aspon z pohladu JMS). > > > > -- > Patrik Beno > J2EE Software Architect > http://patrikbeno.net -- Lukas Zapletal http://lukas.zapletalovi.com
