Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!sdd.hp.com!hplabs!hpda!hpcuhc!dhepner
From: dhepner@hpcuhc.cup.hp.com (Dan Hepner)
Newsgroups: comp.databases
Subject: Re: Any TUXEDO users here?
Message-ID: <2060009@hpcuhc.cup.hp.com>
Date: 24 Jan 91 02:21:48 GMT
References: <DENAP.91Jan10122420@alta.sw.stratus.com>
Organization: Hewlett Packard, Cupertino
Lines: 69

From: brian@edat.UUCP (brian douglass personal account)

>The RM talks to the TM through the XA
>interface as defined by X/Open.  If a product is XA complient, it
>should be able to talk to the TM.  I am not sure if the FE must
>also be XA compliant to talk to the TM.

Well, this is the _promise_ of the XA interface standard,
but there's plenty of reason to believe that it will never
be that simple.

First off, there is today only a preliminary XA spec, and
it is still subject to changes of arbitrary complexity.  Hopefully,
the basic mechanisms will survive into the final standard,
but almost certainly there will be significant changes.

Secondly, the XA standard will probably allow for different
ways to do things, such that an arbitrary RM will be unlikely
to painlessly interface with an arbitrary TM. 

X/Open uses Application Program (AP) instead of FE.
Eventually, after the XA spec is competed, X/Open will
complete an AP - TM interface.  There is no such spec today.  
So in that sense, the AP will similarly be expected to be 
compliant. 

>I understand Oracle has an XA interface currently
>working, and Informix is rumored to have one in the wings.  This
>makes sense since Informix is ATT's product of choice.

One interpretation of the recent announcements (and lack thereof)
from RM vendors is that they all want to keep as wide a market
as they can for their products.  This only makes sense.  As such,
they can be expected to interface to any TM which shows promise
to extend their market penetration.

>All the reading of literature and ad 
>material is fine, but now I want to do some hands on.  If desired,
>I will post a report of what I find to the net, or just e-mail to
>those who wish to hear if the response is less.

I for one look forward to reading your posted experiences.

>IMHO Tuxedo and/or
>ITran for small 386/486 systems could have enormous impact for Unix
>on the Desktop and OLTP.  I can get 20TPS out of a 386 Compaq for
>about $20,000.  $1,000/TPS is an enormous reduction in
>price/performance versus typical OLTP systems running $7,000+/TPS.

Careful.  There is no good transformation between "benchmarking TPS"
and "TPS on some real application".  Further, there are no good
transformations between the various kinds of "TPS".   What kind of 
TPS are you reporting, (TPC-A? TPC-B? TP-1?), and how was it measured. 
At best, these numbers are only comparable with similar results on
other machines.  At worst, their information content is limited
to a measurement of the cleverness and or sleaziness of the benchmarkers 
who generated the numbers.

>Since Tuxedo also supports 2-phase commit, low-cost
>High/Availability systems are now within reach.
>Brian Douglass			Voice: 702-361-1510 X311

Careful. Very few "off the shelf" systems have good recovery
mechanisms for such configurations, and it's easy to underestimate
the difficulty.  Indeed, 2PC protocols can keep your database
consistent, but they won't help get things started back up again
when something goes down.

Dan Hepner