Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!samsung!usc!zaphod.mps.ohio-state.edu!uwm.edu!bionet!agate!ucbvax!unisoft!fai!sequent!dafuller From: dafuller@sequent.UUCP (David Fuller) Newsgroups: comp.databases Subject: Re: Any TUXEDO users here? Message-ID: <50916@sequent.UUCP> Date: 18 Jan 91 07:02:21 GMT References: <2060007@hpcuhc.cup.hp.com> <13333@blia.sharebase.com> Reply-To: dafuller@sequent.UUCP (David Fuller) Organization: Sequent Computer Systems, Inc Lines: 65 In article <13333@blia.sharebase.com> miket@blia.sharebase.com (Mike Tossy) writes: >In article <2060007@hpcuhc.cup.hp.com>, dhepner@hpcuhc.cup.hp.com (Dan Hepner) writes: >> The first relevant fact is that _Unix_ transaction monitors in >> general, and Tuxedo/T in particular, have only begun to penetrate >> the Unix OLTP market. Thus, the base of end user commercial customers >> today is somewhat limited. > >Since they have only begun to penetrate the market, perhaps someone will be >good enough to explain what they are and when they are useful? The wizzened IBM or Tandem hand would claim that the assertion of "recent market penetration" is equivalent to "UNIX market immaturity". Assuming this is not a marketing tease by our friends at ShareBase, I would like to give y'all a brief talk about TP Monitors. Waggish view: It's a cheap trick to save RAM and eliminate the contention and resource consumption implicated by a 1:1 relationship between users and their database servers. Realism in previous proprietary environments: Pragmatic view of DBMS environments; akin to the invention of the statistical multiplexer. Desired functionality: Geographic independence of transaction service and the application's ignorance of response time requirements, geographic actualities, and atomic update of the state of some customer's business. If you look at the first-brush attempts by UNIX developers to get OLTP functionality driven onto UNIX, you see that each application process is tied to a back end which is responsible for DBMS service. This is bad. Tandem proved it was bad. IBM knows it is bad. The fact is that if you have 1 backend associated with a frontend, the backend is not utilized very well, and from the point of view of the backend, reserving vital resources requires far too many cycles because there are usually a lot of 1:1 backends that lay idle. You waste time inventing protocols that roster the "don't care" conditions. If you inject a layer between the front and back ends, you can assert whatever semantic benefits you need; that you do not need to coordinate an n:n environment and you can also benefit from the reduced worst case locking assumptions because you're asserting the n:m relationship between front and back ends. If you are smart you can let the front end do inquiries against a large shared memory buffer (on an SMP machine) knowing that because the tables you reference have a fixed update schedule, locking is not a problem; let the LRU algorithm of the CPU decide what pages are hot. The bottom line is pragmatic conservation of resource in today's OLTP environment for UNIX. For Tandem, it is the irrelevance of locality of both data and processor. For both it is the ability to establish rational constraints between the functional requirements of users and coherent DBMS. > >-- >Mike Tossy ShareBase Corporation (part of Teradata) >miket@blia.bli.com (used to be Britton Lee) -- Dave Fuller Sequent Computer Systems Think of this as the hyper-signature. (708) 318-0050 (humans) It means all things to all people. dafuller@sequent.com