Re: Redundant Informix databases and Tuxedo/T

> My questions and comments: > > (1) What is the "Tuxedo/T TP Monitor" and how would it (a "monitor") be used with respect to redundant database transaction processing? > Tuxedo System/T is a product from AT&T that coordinates distributed transactions across one or more DBMSs, using 2-phase commit. > (2) Since Informix will only allow an application to access ONE database at a time, it seems that the application needs to keep track of the 'before' and 'after' states of the records being modified to be able to perform a 'rollback'. > The way you write the application is that the client side simply deals with a screen and sends a message to the Tuxedo/T system. This then routes the message to one of several server processes; each of these contains the application logic to query/update the database for the transaction required. The client side of the application has NO SQL code in it at all; the server side has NO screen handling code at all. Each server process in this example would access only ONE database; Tuxedo coordinates the two and makes sure that the whole forms a correct distributed transaction. > (3) This sounds somewhat like implementing a "two-phase commit" IN THE APPLICATION as opposed to within the database engine. > The two phase commit is not in the DBMS, as you say; it is in fact in Tuxedo, rather than in the application. > (4) Does anyone know of Informix even PLANNING this type of functionality in the near future? > You're best off asking them. However, they appear committed to interfacing to Tuxedo, because this conforms to the X/Open XA interface standard and is also an entree to the wide world of serious OLTP. I reckon the industry is going to go to an architecture of distributed TP monitor plus DBMS to get distributed OLTP over multiple vendor DBMSs. Other examples include Transarc TP and NCR Top End. > (5) Which Informix Database product is this a reference to? Standard Engine? On-Line? Informix-Online > > I am truly interested in any/all responses because we have a need for this type of functionality in our product. If there's a reasonable solution, I'd like to pursue it. Another point -- with the AT&T takeover of NCR, there is a chance that Tuxedo will not be developed in the future, since Top End competes with it. However, the XA interface should give you some investment protection. As for 2-phase commit for redundant databases -- I looked into this for an Ingres application, and came to the conclusion that 2-phase commit is not really enough (though it is fine for distributed databases). The reason is that when the 2PC coordinator site goes down in the second phase of commit, no-one else knows what decision to make, so they must hang around with locks while this site recovers. This was not acceptable for our application, so we ended up plumping for 3-phase commit, which avoids this situation (at the cost of extra logic to reliably detect a network partition, which is catastrophic for 3PC). > > Joseph P. Tokarski email: tokarski@nms.gdc.portal.com > Senior Software Engineer phone: (203) 758-1811 ext. 7067 > General DataComm, Inc. > I'd be interested to find out if you get redundant databases working with Tuxedo or another product. Richard =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Richard Donkin Hoskyns Open Systems Division (richardd@inset.co.uk) 190 City Road, LONDON EC1V 2QH UUCP: ...!ukc!inset!richardd Tel: +44 71 251 2128 Fax: +44 71 251 2853