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: <1215@smokey.UUCP>
Date: Fri, 31-Jul-87 12:10:27 EDT
Article-I.D.: smokey.1215
Posted: Fri Jul 31 12:10:27 1987
Date-Received: Wed, 5-Aug-87 05:32:58 EDT
Organization: Cognos Incorporated, Ottawa, Canada
Lines: 92

In a recent article in comp.database, utcsri!vassos (Vassos 
Hadzilacos) writes:

| In response to my question as to the problems of "degree 3"
| consistency in connection with on-line trasnsactions, Gary
| Puckering gave some interesting scenarios illustrating these
| problems.
| 
| It seems to me that the main point of his examples is that the
| trouble is caused by transactions holding exclusive locks on
| records and/or indices for too long, thereby forcing other
| transactions to wait too much. One of the remedies he suggests
| is lowering the degree of consistency.
| 
| I disagree with this remedy for the following reasons: The only
| correct way of interleaving transactions in a general purpose
| system is by enforcing serialisability. 

This may come as a great surprise to thousands of designers who have
built applications using more "primitive" database systems like IMS,
TOTAL, ADABAS, etc.

I can't help but wonder: if degree 3 consistency and protection
against phantoms is so wonderful, how did we ever got along without it?

| I think system designers who make serialisability the default in
| concurrency control have actually made the right choice.

I think I can agree with this, the operative word being "default".
Unfortunately, many relational database systems don't give you a
choice, and that is what I object to.  In a 4GL you can enforce
consistency within an application *because* you have more knowledge of
the semantics of transactions than does the underlying database.  
So, I want the option of using degree 2.

| In connection to the issue of performance, the following point
| (made by Jim Gray in his paper "A transaction model") is relevant:
| 
| 	"In the experiments we have done, degree 3 consistency has
| 	a cost (throughput and processor overhead) indistinguishable
| 	from the lower degrees of consistency." 
| 
| Even though I know nothing about the experiments mentioned, I put
| much weight in this statement, coming as it does from the mouth
| (pen? keyboard?) of the person most responsible for the formulation
| of the theory of "degrees of consistency".

Jim Gray's reputation speaks for itself.  However, his opinions of the
validity of degree 3 consistency can hardly be considered impartial.
Theory and practice are not the same.  Show me an application running
on a commericial dbms with enforced serializability which has higher
transaction throughput than the same application using a more
conventional dbms.  My experience, and the weight of evidence that I
have seen, suggests that enforced serializability is a major cause of
low concurrency in on-line transaction processing systems.

Maybe the problem has been that most implementations of
serializability are bad.  I can accept that the theory is right and
the implementations are wrong.  But I can't live with it.  I need
higher throughput, not lower.

| Of course, the performance problem Gary has pointed out is still
| there. One possible avenue that could lead to a reasonable solution
| without compromising serialisability is through the use of mutliple
| versions. 

I agree with you on this 100%.  In fact, I've tested the performance
of two commercial database systems available on VAX/VMS, one which
used multi-versioning and one which didn't.  This was the major
architectural difference between the two systems.  In high concurrency
situations, the single-version system generated numerous unnatural
deadlocks which lead to transaction failures.  The multi-version
system had no unnatural deadlocks.  Consequently, its throughput rate
was almost double that of the single-version system.  (This was
despite the fact that on straight i/o operations, the single-version
system was somewhat faster.)

This may be an example of a good implementation of enforced
serializability.  At the recent SIGMOD conference, a representative from
Oracle (R. Bamford, I believe) said that the new Oracle*XTP would
employ multi-versioning techniques to achieve high throughput in
on-line transaction processing applications.  So, this seems to be the
latest implementation technique for serializability.

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!)
-- 

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