Ahoj,

a proc to chcete programovat?

a) muzete pouzit prostredky serveru, napr. Weblogic nebo Oracle umi propagovat transakcni kontext skrz RMI.

b) muzete propagovat transakcni context z JTS rucne (XID) ... prijemci musi "jen" pouzivat stejny transakcni server.

  Lukas


Lukas Zapletal wrote:
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



Odpovedet emailem