home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / database / 6255 < prev    next >
Encoding:
Text File  |  1992-08-21  |  1.9 KB  |  47 lines
  1. Newsgroups: comp.databases
  2. Path: sparky!uunet!decwrl!world!edwards
  3. From: edwards@world.std.com (Jonathan Edwards)
  4. Subject: Re: Hot Standby DBMS's
  5. Message-ID: <BtDAt7.L5J@world.std.com>
  6. Organization: The World Public Access UNIX, Brookline, MA
  7. References: <BtB5us.MsD@world.std.com> <BtCM7B.FyG@cup.hp.com>
  8. Date: Sat, 22 Aug 1992 04:22:19 GMT
  9. Lines: 36
  10.  
  11. In article <BtCM7B.FyG@cup.hp.com> dhepner@cup.hp.com (Dan Hepner) writes:
  12. >From: edwards@world.std.com (Jonathan Edwards)
  13. >
  14. >>Lock races are inherent functionally: what happens when two operators want
  15. >>to update the same record.
  16. >
  17. >While a race in one sense, this is a benign race unlike the disruptive
  18. >race described by:
  19. >
  20. >>My point is that the winner will not necessarily be the same on a 
  21. >>system recieving a copy of the input stream.
  22. >
  23. >If so, your transactions will deadlock, and will not complete. In the
  24. >system described, all locks must be obtained on all systems before the 
  25. >transaction can complete.  The locking behavior is that of two unrelated
  26. >databases.  This is not a claim that there is no problem here: the races 
  27. >must be prevented in order to do any work, a well known problem in
  28. >transactional application design.  But that inability to do work is 
  29. >the penalty of screwing up, rather than an out-of-sync copy of the 
  30. >database or some other manifestation of non-serialized behavior.
  31. >
  32. >Dan Hepner
  33.  
  34. I think you are changing the subject.
  35. I was replying to a proposal that suggested I could maintain a perfect
  36. copy of a database by simply running the same input stream against the same
  37. application code. I pointed out that race conditions are not deterministic.
  38. You are disagreeing with me while shifting the subject to
  39. some sort of general distributed database with replicated data and
  40. distributed locking. That is a whole nother approach to the problem, and
  41. is the subject of another ongoing thread. So lets save some bandwidth and
  42. put it down.
  43.  
  44.  
  45.  
  46.  
  47.