Path: utzoo!attcan!uunet!indetech!rec From: rec@indetech.com (Rick Cobb) Newsgroups: comp.databases Subject: Re: Any TUXEDO users here? Summary: Transaction Monitors are way cool Keywords: LONG, TUXEDO, OLTP Message-ID: <1991Jan23.235807.12928@indetech.com> Date: 23 Jan 91 23:58:07 GMT References: <1991Jan11.164445.22320@oracle.com> <2374@edat.UUCP> <51164@sequent.UUCP> Reply-To: rec@indetech.UUCP (Rick Cobb) Distribution: comp.databases Organization: Independence Technologies, Inc. Fremont, CA Lines: 122 Disclaimer: Author bears full responsibility for contents of this article In article <51164@sequent.UUCP> dafuller@sequent.UUCP (David Fuller) writes: >I think Brian is mostly right on, but I'd like to respectfully pick a few nits. >In article <2374@edat.UUCP> brian@edat.UUCP (brian douglass personal account) writes: >>Tuxedo runs currently on a variety of platforms, and can easily be >>ported to any SVR3 (naturally) or above platform. There is a >>completed port to SVR4 on the 386 for ATT Unix. 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. > >I would be a little careful about this number; the figure you quote >does not include onsite service, history file maintenance, or other >significant costs (not to mention system admin costs). > > ... > >>Since Tuxedo also supports 2-phase commit, low-cost >>High/Availability systems are now within reach. > >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.) Thanks, Brian, Dave (and Dan Hepner) for summarizing a lot of the issues. Let me see if I can put some of this stuff into the perspective I push around at ITI (i.e., these aren't necessarily ITI's opinions, they're mine -- but I'm fairly loud). 1. Dave's right on the 2-phased commit being mostly about data distribution, rather than high availability. In many (certainly not all) cases, replicated data with a good application-level log can do the redundancy job without the cost. The fundamental problem in high availability is takeover, not redundancy, at least at this stage of the game. TUXEDO is helpful, but not perfect, in this regard. Things will get better. 2. The importance of transaction monitors (TMs) in UNIX goes beyond the "two process" client/server model proffered by the DBMS companies. For example, Sybase and Ingres both have the ability to have a single process serve multiple workstation windows (or client terminal processes). Why do I need a TM with these guys? Because I don't necessarily want to field every bit of logic in my application into those client processes: I want them as light as possible, so I can handle more of them with less RAM, or support more active applications per workstation. Ingres and Sybase would tell me to write my application as "stored procedures" or as "Open Server(TM)s". Why would I want to buy into a proprietary language for my application coding? If I write my application as an "application server" within the ISO 10026 model, I can write it in normal languages (C, C++, COBOL,...) using normal DBMS interfaces (embedded SQL) and expect some portability across DBMS's (and TM's in the long run). I get essentially the same performance and administrative characteristics as the stored procedures, because I run them the same way: statelessly and under centralized control. I send them something, they work, they send me an answer and go on to work on the next "terminal." This "three-process" (actually "n-process") model gets even more important when some of the things I want to do in a transaction are CPU-intensive instead of I/O intensive. By splitting the "services" within my application onto multiple application server processes, I can field the CPU-intense services on high-MIPS boxes, without bogging down the I/O intensive processes on the high I/O boxes. 3. The connection model gets even worse when workstations hit the picture. A normal user on a workstation will hold 4-10 applications "in reserve" as icons. In many two-process models, these clients will run over a megabyte of RAM a piece, both at the client and on the resource manager. (i.e., one on the client box, and one on the server) [Some DBMS companies are better on the backend than this.] When you're fielding a 1000 + workstation network, the cost of RAM/workstation (plus the 5G of RAM for the server) becomes prohibitive or impossible to deploy. By staying stateless and connectionless, these clients can be as small as their window systems let them be. 4. We try to let the workstation environment do the non-database work for us -- but the database intensive work with lots of conditional logic needs to run near the data. For example, in insurance claims processing we've focused workstation MIPS on things like image presentation and 3270-emulation (for quick access to CICS stuff without coding UNIX OLTP transactions). We focused server MIPS on the database *and* on the nasty conditional logic (read "rule system") necessary to figure out if a claim should be paid. If the rule system starts to require more MIPS than I/O, it may be moved onto a computational server. 5. It's important to have facilities to talk to wierd devices like point-of-sales terminals out on X.25 networks. You don't necessarily need to multi-thread clients, like in CICS or Pathway, since X.25 takes care of most of the multiplexing for you (for the applications we've done so far, SVC's [switched virtual circuits] have been the way to go). Besides, some of the best X.25 software runs on cheap hardware anyway, and you've got a a transaction monitor to make the LAN transparant. Treating everything like it can run curses or X is a mistake: the OLTP world is based on getting terminals close to the customer, and the right terminal for a customer may be the wierdest damned thing you ever saw. It's nice if you can use the same configuration of software to run against a POS terminal *and* an X-window. There's lots more to say; I'll try to be shorter with my next article. >>Brian Douglass brian@edat.uucp >Dave Fuller >dafuller@sequent.com Hi Dave! Long time no SIGBAR! -- ____*_ Rick Cobb rcobb@indetech.com, \ / / Independence Technologies {sun,pacbell,sharkey}!indetech!rcobb \/ / 42705 Lawrence Place FAX: (US) 415 438 2034 \/ Fremont, CA 94538 Phone: (US) 415 438 2004