Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!hplabs!hpcc05!hpyhde4!hpycla!hpcuhc!dhepner
From: dhepner@hpcuhc.cup.hp.com (Dan Hepner)
Newsgroups: comp.databases
Subject: Re: XA Compliant RDBMSs
Message-ID: <2060011@hpcuhc.cup.hp.com>
Date: 8 Apr 91 21:22:26 GMT
References: <1120@tetrauk.UUCP>
Organization: Hewlett Packard, Cupertino
Lines: 45

From: nick@tetrauk.UUCP (Nick Rumble)

>>The Developer's Specification of XA, as yet unpublished by
>>    X/Open.
>
>In fact, the Developer's Specification of XA is now available 
>through X/Open.

From: bgolden@informix.com (Bernard Golden)

>The Developer's Specification is not available yet.  The Preliminary
>Specification was released in April 1990.  The two are different.  The
>Developer's Specification will incorporate comments made about the
>Preliminary Specification by various interested parties.  The Developer's
>Specification should be out late this year.
>>
>>-b

The direct workings of the XTP working group are "X/Open confidential", 
which means that detailed reports are made completely available to X/Open 
members and associate members.  Both HP and Informix receive this 
information.  Bernard and I are right, although no schedule has 
been publicly committed to.

>>It's also quite possible to make use of Tuxedo/T - DBMS
>>combinations which have no utilization of the XA interface at all.
>
>True. But - and this is a *big* but, should one or more elements
>within a distributed TP application fail for some reason, remote
>transactions belonging to non-compliant DBMSs would remain in a
>pre-committed state. Having no control over them, the TP monitor
>could not instigate the necessary recovery (commit or abort)
>procedures, leaving the DTP application in an inconsistent state.
>
>Nick Rumble

This big but presumes that the reason you are using Tuxedo/T is
to do distributed transactions.  Others have found usages in
non-distributed environments.  For example, it may be possible to
put up a DMBS world which is much smaller than the number of
actual users; the DBMS sees a small number of very busy users,
as compared to a large number of relatively inactive users.  This
ends up being a real advantage for some configurations.

Dan Hepner