ppoblete@toqui (Patricio Poblete) (05/29/90)
Some time ago, I asked the following question: > We are looking for examples of Unix-based transaction processing systems > in actual operation. What kind of transaction processing monitors are > being used? We have read about one from AT&T, called "Tuxedo". What has > been the experience of people using it? Here is a summary of the replies I got: -------------------------------------------------------------------------- From: uunet!erbe.se!prc (Robert Claeson) I don't have any experience with it, but this is what I know: * Source license goes for ~$180,000. * Consists of two parts -- System/T for terminal monitoring and System/D for database management. * System/D is a home-grown database system with indexed files and all sorts of other facilities one need for transaction processing. * It is possible to license only one of the parts. * It is possible to modify an existing RDBMS and have it work with System/T. I believe that Oracle is porting their database system to work with Tuxedo. Robert -------------------------------------------------------------------------- From: David Fuller <uunet!sequent!dafuller> The idea behind a TX monitor is to conserve resources and control their allocation. At least in UNIX. On fault tolerant systems the idea is both this and also to ensure easy application-level fault tolerance. In UNIX, particularly with 1:1 requester/server designs, the biggest initial win is to conserve private dataspace. Currently, with the one process per server model, each server must allocate enough private dataspace to satisfy the basic requirements of the Oracle server. The observed performance shows that most servers sit idle and cause significant virtual memory activity (page faulting, minor and major) each time they are awakened and asked to do work. The solution is to eliminate the multiple queues implied by a 1:1 requester-server relationship and allocate only as many servers as the production environment requires. Tuxedo/T helps enable this by implementing the basic multiplexing logic necessary to convert the "one person per teller" to "one line waiting for many tellers", thus load-levelling the available servers. I mentioned fault tolerance. Conceptually, it is important to maintain a stateless sever in a fault tolerant environment, at some level, so that the server may be discarded arbitrarily. This permits location independence of a logical server so that the service is provided as requested and the service is discrete, distinct, and unreliable; the application always checks the error code and either retries or conveys its apologies that the requested action didn't happen. So the eradication of a node isn't catastrophic in terms of controlling an enterprise. The ultimate solution for UNIX right now is to have a server that handles more than one thread at once and orchestrates its I/Os to keep the data moving consistently; and talks effectively to the application to make sure the intent of the requester is communicated to the DBMS; that ad hoc inquiries which scan each tuple of the DB do not inhibit the users which are taking orders and changing the state of the immediate business. And to keep the CPU utilization up and the investment in iron down... I believe TX monitors are reasonable subjects for puritan discussion now because they resemble a statistical multiplexer within the otherwise "pure" UNIX user-level environment. And I believe I'd rather do without the layer, because it repeats some previous mistakes (while admitting to the requirement that UNIX acquire some level of pragmatism). (but that's not the debate...) Dave -- Dave Fuller Sequent Computer Systems Think of this as the hyper-signature. (312) 318-0050 (humans) It means all things to all people. {uunet,sun,...}!sequent!dafuller -------------------------------------------------------------------------- From: ron@rdk386.uucp (Ron Kuris) Unify 2000 is a Unix-based OLTP system which has (or will shortly have) "uperf", the Unify Performance monitor. On the right side, near the middle of the screen is a "load factor" which shows the average number of TPS over the last 1, 5, and 15 minutes. It also gives this factor on a per-user basis. There are even options to log this information into a file so you can analyse your busy times. Other information available are the free log space information, free shared memory information, error log information, syncpoint info, user info, db state info, cache statistics, # of db operations since last sync, etc., all on one handy screenful. It is "intended for use on an unused terminal [...] to be run continuously to monitor database performance and operations". "uperf" will be available in release 1.2.0.0.0 or later of Accell/SQL for Unify 2000, available this summer. It may also appear in some earlier releases; I'm not 100% sure. TPS isn't a great measurement, though, because some transactions are very short and others are long. 5 long transactions per second is great, but 5 short transactions per second is terrible. -- -- ...!pyramid!unify!rdk386!ron -or- ...!ames!pacbell!sactoh0!siva!rdk386!ron It's not how many mistakes you make, its how quickly you recover from them. -------------------------------------------------------------------------- From: uunet!indetech.com!rec (Rick Cobb) Our company specializes in commercial OLTP systems for UNIX based on Tuxedo System / T. We have several systems in development now, and one production site coming up currently. The Tuxedo system has two components: System / T, which is the transaction monitor and environment; and System / D, a CODASYL-like DBMS. Given the commercial viability of network model DBMS's (none), the piece of Tuxedo that's most interesting is System / T, usually pronouned "slash T", at least around here. Tuxedo's transaction model is kind of a cross between TMF (tandem) and CICS. To implement an application, you set up clients (single-threaded, usually) which send messages to "services". Services are stateless C subroutines. The subroutines can be packaged into executables which offer more than one service; each executable can then be run as multiple processes (servers). Message sends and receives can be done asynchronously or synchronously, depending on whether the process is acting as a client or server. DBMS's are integrated as "resource managers"; i.e., processes which must participate in the commit. /T supports two-phase commit if the underlying resource managers do. Tuxedo has a strong set of monitoring tools; service and server availability, response times, etc., are available. It is also DBMS-independent. System / T Version 4.0 is a conformant subset of the (current) X/Open DTP (distributed transaction processing) specification. To the extent that DBMS companies buy into the X/Open DTP spec, they will be available as resource managers under System / T. Our production site handles particularly nasty transactions: insurance claims (pharmacy-card based pharmaceutical claims, arriving from the stores, with customers waiting). Our response time requirement is tight, but it takes around 20 database interactions to perform that transaction; by the time we get to our next release, it'll take close to 30. We are getting very nice performance out of a Pyramid MIS/Server 12/4 in this environment (4 15 mip risc processors, 10 G total SMD disk, mirrored for 5 G available storage). We've run this configuration at 15 pharmacy claims / sec on ORACLE; we have not completed the tuning of this environment. #ifdef Commercial_On Programming at the subroutine and message level, however, is a lot of pain. In addition, as System / T has been upgraded recently to Version 4.0, it gained the ability to distribute services and clients on a network, but lost some other capabilities which are *extremely* important to resource managers. Those will be added back in as time goes on and the rest of the X/Open DTP is implemented. However, the alternative to buying AT&T source or binaries for Tuxedo from AT&T is to buy them from a third party with experience in Tuxedo application development. It's helpful if that third party also provides higher level tools, like event management, SNMP/UNMP network management facilities, a transaction language that makes all the messaging and client/server setup transparent to your application developers (thus making multi-lingual programming much easier, among other things), etc. It's also helpful if that company has helped one or more DBMS companies over the integration hurdle. The company I work for is such a third party; we also license binary distributions of Tuxedo / T with some performance enhancements (particularly for symmetric multiprocessors); our ports are called System / iTi (AT&T has the same restrictions on the use of Tuxedo and System / T trademarks as they do on UNIX). Having a complete transaction monitor (independent of the DBMSs and hardware used) to manage your distributed TP environment gives you a way to manage heterogeneity in your system. If Informix is right for one application, you use it; if ORACLE is right, you use it. If C is the right language for a particular bit of logic, you write in C; if C++ or COBOL is appropriate for particular services, you can write in them. If you need an expert system in the mix, you can decide to chew those mips on a separate processor from where the database is. Etc. I believe that separate transaction monitors, *particularly* System / T, are the way that UNIX transaction environments need to go. The idea that there will only be one (type of) resource manager in your network, or used by an application, is silly -- the real world demands that you be able to commit an EFT transaction to both an off-site EFT service and your local database. It presupposes that you can work with more than one DBMS. It assumes that you can live in a world that also has CICS- or TMF- based transaction systems. These kinds of demands make it important to separate the transaction monitor from the individual DBMSs (and to as great an extent as possible, from the OS). While System / T can't quite do all that right now (in particular, the CICS and TMF world is still a bit off, though we've done some integration work there) it's the best hope we have so far. #endif -- ____*_ Rick Cobb rcobb@indetech.uucp, sun!indetech!rcobb \ / / Independence Technologies An opinion is as a drop of rain. \/ / 42705 Lawrence Place That this drop fell does not mean \/ Fremont, CA 94538 my employers are all wet. =========================================================================== Well, thanks to all who answered. Judging by the number of "me too" messages I received, there is quite a bit of interest in OLTP applications under Unix. The application we have in mind involves a database with some 16 million records, with some 200 terminals. Right now, all this runs on two aging DEC-10s, with software that is absolutely non-portable. Understandably, the possibility of choosing a solution based on an "open systems" approach is very appealing. On the other hand, we are forced to be conservative (this is a project that just can't fail), and from that point of view, it seems that Unix OLTP still needs a year or two to mature. Thanks again, Patricio Poblete ppoblete@uchile.CL
sdo@cbnewsl.att.com (scott.orshan) (06/02/90)
>Some time ago, I asked the following question: > >> We are looking for examples of Unix-based transaction processing systems >> in actual operation. What kind of transaction processing monitors are >> being used? We have read about one from AT&T, called "Tuxedo". What has >> been the experience of people using it? > >Here is a summary of the replies I got: > We in the TUXEDO Development Organization of the UNIX Software Operation have been following this discussion of OLTP under Unix, and would like to throw our 2 cents in. We've pared down the included text as much as possible. Most of the comments have been favorable and accurate, but there are some misconceptions that should be cleared up. >-------------------------------------------------------------------------- >From: uunet!erbe.se!prc (Robert Claeson) > >I don't have any experience with it, but this is what I know: > >* Source license goes for ~$180,000. >* Consists of two parts -- System/T for terminal monitoring and > System/D for database management. >* System/D is a home-grown database system with indexed files and all sorts > of other facilities one need for transaction processing. >* It is possible to license only one of the parts. >* It is possible to modify an existing RDBMS and have it work with System/T. > I believe that Oracle is porting their database system to work with Tuxedo. > >Robert > System/T is not a Terminal Monitor. It is a Transaction Manager. Its two main functions are to implement the distributed Client/Server model and to enable and coordinate Distributed Transactions. This can be done on heterogeneous networks of UNIX machines. Client processes can be running front-ends on terminals (we supply a Forms package ourselves), and in that respect System/T can resemble a Terminal Monitor, but that is not its primary purpose. System/D is no more "home-grown" than any other DBMS. The TUXEDO System, in one form or another, has been in use for over 7 years both inside and outside of AT&T. The price quoted above is mildly accurate, with the note that Systems /T and /D are usually sold separately. (The above price is based on the combined cost of /T and /D.) As with any software license from USO (e.g., UNIX), there are lots of considerations that can only be answered by talking to someone here. There are phone numbers at the end of this article. Note that, as with the UNIX System, most people buy a binary version of our products at a considerably lower cost than the source. >-------------------------------------------------------------------------- >From: uunet!indetech.com!rec (Rick Cobb) > >Our company specializes in commercial OLTP systems for UNIX based on >Tuxedo System / T. We have several systems in development now, and one >production site coming up currently. > >The Tuxedo system has two components: System / T, which is the transaction >monitor and environment; and System / D, a CODASYL-like DBMS. Given the >commercial viability of network model DBMS's (none), the piece of Tuxedo >that's most interesting is System / T, usually pronouned "slash T", at least >around here. Yes, that's the correct pronunciation. ITI was one of our first outside licensees when they purchased Release 3.0 of TUXEDO. They developed a Toolkit on top of TUXEDO Release 3.0, and we believe they are going to make it available on Release 4.0. Release 4.0 of TUXEDO is the release that incorporates Networking and Distributed Transactions. We wouldn't say that the interest in network model DBMSs is "none", as evidenced by the widespread use of /D, and the fact that a large percentage of customers who buy /T also buy /D. > >[Deleted Stuff] > >I believe that separate transaction monitors, *particularly* System / >T, are the way that UNIX transaction environments need to go. The idea >that there will only be one (type of) resource manager in your network, >or used by an application, is silly -- the real world demands that you >be able to commit an EFT transaction to both an off-site EFT service >and your local database. It presupposes that you can work with more >than one DBMS. It assumes that you can live in a world that also has >CICS- or TMF- based transaction systems. These kinds of demands make >it important to separate the transaction monitor from the individual >DBMSs (and to as great an extent as possible, from the OS). > >While System / T can't quite do all that right now (in particular, the >CICS and TMF world is still a bit off, though we've done some >integration work there) it's the best hope we have so far. > We haven't kept it much of a secret that we are working on providing the capability of making service requests from a UNIX Client to a CICS Server. > >In addition, as System / T has been upgraded recently to Version 4.0, it >gained the ability to distribute services and clients on a network, but >lost some other capabilities which are *extremely* important to resource >managers. Those will be added back in as time goes on and the rest of the >X/Open DTP is implemented. > It's true that certain ways of using Release 3.0 were cleaned up in Release 4.0, and that made it harder to do certain things, but we are working on "clean" replacements for those features that fit in with the Distributed Model. These will be available in the very short term. >-- >____*_ Rick Cobb rcobb@indetech.uucp, sun!indetech!rcobb > >Well, thanks to all who answered. Judging by the number of "me too" messages >I received, there is quite a bit of interest in OLTP applications under >Unix. > >On the other hand, we are forced to be conservative (this is a project that >just can't fail), and from that point of view, it seems that Unix OLTP still >needs a year or two to mature. We'll have to disagree on that one. Many applications are finding UNIX to be just fine for OLTP, given the availability of the OLTP packages that can be purchased right now. > >Thanks again, > >Patricio Poblete >ppoblete@uchile.CL > > For more information, please contact one of the following people: Enzo Greco Glenn Rose 201-522-5173 201-522-6477 attunix!esg attunix!uso!grr esg@attunix.att.com grr@uso.att.com ================== Scott Orshan 201-522-5063 sdo@attunix.att.com
sdo@cbnewsl.att.com (scott.orshan) (06/08/90)
In a previous article, I responded to some statements by Robert Claeson: > >From: uunet!erbe.se!prc (Robert Claeson) > > > >I don't have any experience with it, but this is what I know: > > > >* Source license goes for ~$180,000. > >* Consists of two parts -- System/T for terminal monitoring and > > System/D for database management. > >* System/D is a home-grown database system with indexed files and all sorts > > of other facilities one need for transaction processing. > >* It is possible to license only one of the parts. > >* It is possible to modify an existing RDBMS and have it work with System/T. > > I believe that Oracle is porting their database system to work with Tuxedo. > > > >Robert > > > [My Response] >System/T is not a Terminal Monitor. It is a Transaction Manager. >Its two main functions are to implement the distributed Client/Server >model and to enable and coordinate Distributed Transactions. >This can be done on heterogeneous networks of UNIX machines. >Client processes can be running front-ends on terminals (we supply >a Forms package ourselves), and in that respect System/T can resemble >a Terminal Monitor, but that is not its primary purpose. > >System/D is no more "home-grown" than any other DBMS. The TUXEDO >System, in one form or another, has been in use for over 7 years >both inside and outside of AT&T. > Robert Claeson has informed me that he was just quoting from a presentation made by someone from the UNIX Software Operation. I also I realized that I didn't post our European contact, so here is the correct information for the TUXEDO contacts: Enzo Greco Glenn Rose Vijayakumar Vijayaratnam 201-522-5173 201-522-6477 +44 81 567 7711 attunix!esg attunix!uso!grr attunix!uel!vvk esg@attunix.att.com grr@uso.att.com vvk@uel.co.uk (European Contact) ================== Scott Orshan 201-522-5063 sdo@attunix.att.com