Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!cs.utexas.edu!uunet!mcvax!hp4nl!orcenl!bengsig
From: bengsig@oracle.nl (Bjorn Engsig)
Newsgroups: comp.databases
Subject: Re: Concurrency control in real life
Message-ID: <477.nlhp3@oracle.nl>
Date: 16 Aug 89 07:29:47 GMT
References: <4875@macom1.UUCP> <328@csense.UUCP> <614@anasaz.UUCP>
Reply-To: bengsig@oracle.nl (Bjorn Engsig)
Organization: ORACLE Europe, The Netherlands
Lines: 14

Another example of real life concurrency is this, which I have experienced
my self:

You go to one of the checkin counters in an airport, specify what kind
of seat you want, and is told that e.g. 13B is available.  A few seconds 
later (when the 'COMMIT' key is pressed) 13B is gone!  Apparantly, this
systems follows the 'reread-before-write' rule and not the 'lock-on-read'
rule.  The latter would without doubt give too many seats locked for too
long time and decrease the overall throughput, whereas the former does give
the kind of trouble I've described.
-- 
Bjorn Engsig, ORACLE Europe         \ /    "Hofstadter's Law:  It always takes
Path:   mcvax!orcenl!bengsig         X      longer than you expect, even if you
Domain: bengsig@oracle.nl           / \     take into account Hofstadter's Law"