home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / database / theory / 445 < prev    next >
Encoding:
Internet Message Format  |  1992-09-03  |  1.5 KB
  1. Path: sparky!uunet!spool.mu.edu!sdd.hp.com!hplabs!ucbvax!mtxinu!sybase!houdini!jeffl
  2. From: jeffl@houdini.sybase.com (Jeff Lichtman)
  3. Newsgroups: comp.databases.theory
  4. Subject: Re: What is the _Halloween Problem_ ?
  5. Message-ID: <23055@sybase.sybase.com>
  6. Date: 2 Sep 92 20:13:06 GMT
  7. References: <22838@sybase.sybase.com> <1992Aug28.161050.668@news2.cis.umn.edu> <17loktINN7mi@agate.berkeley.edu> <BtpLzu.Mzx@world.std.com>
  8. Sender: news@Sybase.COM
  9. Organization: Committee to Increase The Entropy
  10. Lines: 19
  11.  
  12. In article <BtpLzu.Mzx@world.std.com>, edwards@world.std.com (Jonathan Edwards) writes:
  13. > In article <17loktINN7mi@agate.berkeley.edu> mao@triplerock.CS.Berkeley.EDU (Mike Olson) writes:
  14. > >transaction semantics force us never to see our own updates, so this is
  15. > >a violation of transaction semantics.
  16. > 
  17. > Why's that? Seem perfectly reasonable to me that I should see my own updates.
  18.  
  19. A single statement should not see the results of its own updates.  In other
  20. words, a statement should base its updates on the state of the data at the time
  21. the statement begins.  To do otherwise would allow for unpredictable and
  22. inconsistent results.  I have already posted an example of this.
  23.  
  24. This is different from saying that one statement in a transaction should be
  25. able to see the results of an earlier update in the same transaction.  I think
  26. everyone agrees that this should happen.
  27. ---
  28. Jeff Lichtman at Sybase
  29. {mtxinu,pacbell}!sybase!jeffl  -or- jeffl@sybase.com
  30. "Saints should always be judged guilty until they are proved innocent..."
  31.