Path: utzoo!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!uchdcc!toqui!ppoblete From: ppoblete@toqui (Patricio Poblete) Newsgroups: comp.databases Subject: Transaction Processing under Unix -- Summary of Replies Message-ID: <2121@uchdcc.uchile.cl> Date: 28 May 90 19:07:40 GMT Article-I.D.: uchdcc.2121 Sender: ppoblete@uchdcc.uchile.cl Organization: U. de Chile, Depto. Ciencias de la Computacion, CHILE Lines: 229 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 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