home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / database / theory / 428 < prev    next >
Encoding:
Internet Message Format  |  1992-08-29  |  1.6 KB
  1. Path: sparky!uunet!sun-barr!ames!agate!triplerock.CS.Berkeley.EDU!mao
  2. From: mao@triplerock.CS.Berkeley.EDU (Mike Olson)
  3. Newsgroups: comp.databases.theory
  4. Subject: Re: What is the _Halloween Problem_ ?
  5. Date: 29 Aug 1992 17:46:13 GMT
  6. Organization: University of California at Berkeley
  7. Lines: 27
  8. Message-ID: <17od55INNih8@agate.berkeley.edu>
  9. References: <1992Aug28.161050.668@news2.cis.umn.edu> <17loktINN7mi@agate.berkeley.edu> <BtpLzu.Mzx@world.std.com>
  10. NNTP-Posting-Host: triplerock.cs.berkeley.edu
  11.  
  12. In <BtpLzu.Mzx@world.std.com>, edwards@world.std.com (Jonathan Edwards)
  13. writes:
  14.  
  15. > In article <17loktINN7mi@agate.berkeley.edu> mao@triplerock.CS.Berkeley.EDU (Mike Olson) writes:
  16. > >transaction semantics force us never to see our own updates, so this is
  17. > >a violation of transaction semantics.
  18. > 
  19. > Why's that? Seem perfectly reasonable to me that I should see my own updates.
  20. > How does this follow from the conventional ACID definition of transactions?
  21.  
  22. if you want a high level of consistency in transaction processing, you must
  23. supply repeatable reads during a transaction.  this means that inside a
  24. single command in a single transaction, you cannot be allowed to see your
  25. own updates.
  26.  
  27. lower levels of consistency don't have this requirement, and (as a result)
  28. don't necessarily guarantee serializability of concurrent transactions.
  29. this violates isolatability (the 'i' in acid).
  30.  
  31. jim gray wrote a paper in the early- or mid-80's defining four consistency
  32. levels, and giving the characteristics of each.  the ref is at work (and
  33. i'm not); email me if you want it, and i'll dig it up.
  34.  
  35.                     mike olson
  36.                     project sequoia 2000
  37.                     uc berkeley
  38.                     mao@cs.berkeley.edu
  39.