Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!dciem!nrcaer!cognos!garyp From: garyp@cognos.uucp (Gary Puckering) Newsgroups: comp.databases Subject: Re: Degree 3 consistency Message-ID: <1301@smokey.UUCP> Date: Thu, 20-Aug-87 18:03:18 EDT Article-I.D.: smokey.1301 Posted: Thu Aug 20 18:03:18 1987 Date-Received: Sun, 23-Aug-87 10:12:17 EDT References: <1215@smokey.UUCP> <18182UH2@PSUVM> Reply-To: garyp@cognos.UUCP (Gary Puckering) Organization: Cognos Inc., Ottawa, Canada Lines: 94 In article <18182UH2@PSUVM> UH2@PSUVM.BITNET (Lee Sailer) writes: >In article <1215@smokey.UUCP>, garyp@cognos.uucp (Gary Puckering) says: >> >>The jury is still out, though, on whether these systems can ever >>outperform "classical" database systems. (I hope they can, I think >>they can, but I don't *know* they can!) > -- > Knowing that they can will be hard to establish. The ideal experiment >would be to give about 50 different teams of professional programmers >a big project to do, and let them use several differnt approaches, >assigned randomly, and include a year for training for each team, >and then see which teams (a) finish first, (b) finish best, (c) write >fastest code, etc etc etc. > >Ah! This is a 50 million dollar study, and not even the Pentagon will >fund it. Let me have one more kick at the can (and then maybe I'll shut up for awhile on this topic). Dr. Codd, in his landmark paper "A Relational Model of Data for Large Shared Data Banks" proposed many interesting ideas, not the least of which was the notion of *consistency*. This idea was further developed by Jim Gray and others. Among the many ways in which a relational system is different from its network and hierarchical predecessors, the inclusion of a formal transaction management scheme is perhaps the most profound. The implementation of degree-3 consistency involves the assumption that the database management system does not have any knowledge of the semantics of the application (i.e. what it is doing in between database operations) and therefore it must "protect" the concurrent transactions from each other. In this sense, it assumes the worst-case. It assumes, in fact, that the application designer may not have taken concurrent transactions into account during design. This is clearly a very conservative position. I could argue that this is too conservative. I think degree-3 is a sensible default, but I also think an application designer should have the option of choosing degree-2. The obvious counter-argument is that humans are too fallible and we shouldn't give the designer a loaded gun. I figure an application designer can always subvert a relational system anyway, by doing things in two transactions that ought to be done in one. Nonetheless, I might concede that if humans were the only things that designed systems, then enforced degree-3 might be best. But humans aren't. Computers design systems too. In particular, 4GL's design systems. So what I will argue is that makers of general-purpose database systems should provide degree-2 consistency, as an option at the call-level interface, because 4GL systems need it. My reasons are as follows: 1. A 4GL is a "computerized" application designer. It can be counted on to obediently generate applications according to the set of rules given it by its creators. If the creator makes a mistake in the rules, that mistake will be made over and over again. It is almost certain to be spotted. 2. These rules provide a framework for consistency. That is, the 4GL can be counted on to generate an application in such a way that inconsistent transactions are not allowed. 3. Because of this, it is reasonable to allow the 4GL to have access to lower levels of isolation -- because a 4GL *does* understand the semantics of the class of applications it can generate. Our 4GL, PowerHouse, supports access to several kinds of indexed file systems, a two-level network database system, a network-hierarchical style DBMS, and two different relational systems. Supporting the relational systems caused us all kinds of problems, primarily due to enforced degree-3 consistency. Allowing us to use a lower isolation level would have eliminated these problems without jeopardizing the integrity of the data (we ensure that) and produced a system capable of supporting more concurrent users. Have any of you "purists" out there really built an on-line transaction processing application using degree-3 consistency? How many concurrent users did it support without running into long wait times and unnatural deadlocks? You know, I think relational databases have gotten a bad name for themselves, performance-wise, not because they are inherently slower than the "classical" systems (in fact, storage structures and access techniques have improved a lot over the last few years). I think they got a bad name because no-one could get the same concurrent performance levels they used to get. And I think it's because of degree-3 consistency! -- Gary Puckering 3755 Riverside Dr. Cognos Incorporated Ottawa, Ontario {allegra,decvax,ihnp4,linus,pyramid} (613) 738-1440 CANADA K1G 3N3 !utzoo!dciem!nrcaer!cognos!garyp