Re: Distributed Transactions: XA

1. Well is it? It seems complex because there is not enought documentation available. Example: in the oracle docu there is witten "if you want more information see the docu of your TP monitor vendor...". And what the hell if I want to write my onwn TP monitor ?
2. Most of the cases yes, because it's the only portable way to access all the diffrent ressource managers. Also the new Object Transaction Monitors require a XA interface from the RM.
3. It will work, as long as you have the STATE of the TRX from the point of the first prepare to the last commit in a persistant storace. You have to restore that STATE if your program crashes in the middle of the transaction. And you have to manage all the RM if one of those crashes -> restart logic ( ask for pending TRX, and decide if they have to be commited or aborted )

Cheers
markus

Marco Machicao y Priemer wrote:
>
> Hi there,
>
> I just started reading about distributed transactions. The first thing
> I learned is that there is a standard (XA) from the Open Group
> for Distributed Transaction Processsing (DTP).
>
> Then I learned, that many vendors support Distributed Transactions
> among servers of the same vendor. (SQLBase, Interbase...) This seems
> to be very confortable and transparent to the user.
>
> Finally I got the impression, that this products do implement DT's
> in their own propietary way (not XA) and they do not offer an
> API conforming to XA.
>
> Finally I read about Transaction Servers (TS) wich implement the
> XA way of doing things.
>
> So now the questions:
>
> 1) Why ist the XA modell so complex?
>
> 2) Will only XA compilant Databases work with a TS?
>
> 3) Why won`t poor mans "2 Phase Commit" work?
>
> //prepare commit operation
> for each (database in transaction) do
> begin
> if not (prepare commit) do
> begin
> rollback everything
> exit
> end
> end
>
> //commit
> for each (active database server) do
> begin
> commit
> end
>
> Thanks.
>
> Marco
Received on Tue Feb 01 2000 - 00:00:00 CET