Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!edat!brian From: brian@edat.UUCP (brian douglass personal account) Newsgroups: comp.databases Subject: Re: Any TUXEDO users here? Message-ID: <2376@edat.UUCP> Date: 28 Jan 91 19:26:07 GMT References: <2374@edat.UUCP> <51164@sequent.UUCP> <51386@sequent.UUCP> Distribution: comp.databases Organization: Electronic Data Technologies, Inc., Las Vegas, NV Lines: 74 In article <51386@sequent.UUCP> dafuller@sequent.UUCP (David Fuller) writes: >>2-phase commit does not necessarily equate to "high availability" >>to me, 2-phase commit has more to do with logical and geographic >>distribution of data than additional reliability. (2 phase commit is >>conventionally the ability of a distributed system to permit unilateral >>abort of all concerned parties in the first phase and abort by only >>the comitter in the second phase. See papers by Gray, et al for >>details.) > > I guess I should edit myself here. The availability of 2 phase > commit fosters 3 phase commit, whereas multiple commiters (with > one dedicated master) handling more than one location for valid data. > > In essence, if the master cannot respond to the commit, its > subordinates can arbitrate mastery and commit. This means that > the DBMS will be OK if the master's gone down and the remaining > interested parties will become more interested and organize them- > selves to ensure the DBMS is available. But this requires advanced > diagnosis of why the original commit failed. > > As we know, asking "why" tends to prove dicey for computers. > The easiest failures to detect tend to be those least likely > to occur... This is, to a degree, what I was talking about in that two-phase commit helps to provide high availability. At UniForum I discussed this point at length with USL about having a replicated database functionality through the two-phase commit protocol to give fail over to a sub-controler that now becomes the master. USL has great interest in doing something like this in Tuxedo, but it is NOT currently possible. They're response was "We don't see why we can't do this in the future". We built this kind of functionality into a DOS based system built around Faircom libraries. Transactions came across the network either from workstations or gateways that act like terminal servers receiving serial input. The transactions hit the main controler, which would either process it itself, pass it on to the sub-controler, or do both. Both machines do a "I'm alive. You alive?" "Yes I'm alive. You alive?" type of interrogation. If the master fails, the sub takes over all processing, while maintaining a sync file of transactions. When the master comes back alive, it processes everything in the sync file, catching up to the sub and resuming its duties as the master. The keeping a sync file on both machines is no real big deal for Tuxedo, or the replication of data. The fail over protocol, as Dave mentioned is the sticking point. But I think we can expect to see something like this in the near future. Rick Cobb, I believe, also mentioned that is important to make your terminal applications as independant from your backend processing as possible, because sometimes you hook in weird stuff. This is absolutely true. In our application our terminals are Slot Machines! People sign up at the casino and receive a "frequent player" card. The more money they put into a slot machine, the more points they receive. All of this transmitted back to a host and processed in real time. So, who knows were your data is coming from sometimes. Does anybody know about TOP END from NCR, or TRANS-ARC? Maybe its time to widen this discussion to Transaction Monitors and not just Tuxedo? Oh, BTW, I will post some of what I found about Tuxedo and other OLTP related products at UniForum. But first I have to tell management. Brian Douglass Voice: 702-361-1510 X311 Electronic Data Technologies FAX #: 702-361-2545 1085 Palms Airport Drive brian@edat.uucp Las Vegas, NV 89119-3715 -- Brian Douglass brian@edat.uucp