Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!ames!ucbcad!zen!xanadu!larry
From: larry@xanadu.uucp (Larry Rowe)
Newsgroups: comp.databases
Subject: Re:  Degree 3 consistency
Message-ID: <3391@zen.berkeley.edu>
Date: Tue, 25-Aug-87 11:12:21 EDT
Article-I.D.: zen.3391
Posted: Tue Aug 25 11:12:21 1987
Date-Received: Wed, 26-Aug-87 06:48:20 EDT
References: <1215@smokey.UUCP> <18182UH2@PSUVM> <1301@smokey.UUCP>
Sender: news@zen.berkeley.edu
Reply-To: larry@xanadu.UUCP (Larry Rowe)
Organization: Postgres Research Group, UC Berkeley
Lines: 39

In article <1301@smokey.UUCP> garyp@cognos.UUCP (Gary Puckering) writes:
>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!)
>> --
>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.
>
Jim Gray will tell you that when he and his collegues at ibm san jose
developed the theory of transactions, they were just formalized what
had already been implemented in IMS.  in fact, jim spent considerable
time studying IMS on-line transaction systems -- particularly the
occurrence of deadlocks.  

So, the ``theory'' that relational systems use was, in fact, implemented
in IMS.  moreover, DB2 uses the same transaction manager as IMS.  consequently,
the xact functionality issue is really an issue of what an individual
system implementer chooses to implement.  some relational systems support
something other than degree 3 consistency, others don't.  

another common problem with relational dbms applications that wasn't a
problem with IMS/DBTG applications is that they can do long queries
(e.g., find all employees that make more than their manager) which will
probably lock the entire employee table (under degree 3 consistency)
unless the implementers do something very sophisticated (e.g., scan locks
where a record/page lock is held only until the record/page has been
read).  problem is that this takes several lines of code to implement
(don't forget the heuristics to look at the query and choose the appropriate
locking).  IMS/DBTG systems didn't have this problem because you couldn't
issue a long query!
	larry