home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / database / 6239 < prev    next >
Encoding:
Text File  |  1992-08-21  |  1.5 KB  |  39 lines
  1. Newsgroups: comp.databases
  2. Path: sparky!uunet!cs.utexas.edu!sdd.hp.com!hpscdc!cupnews0.cup.hp.com!dhepner
  3. From: dhepner@cup.hp.com (Dan Hepner)
  4. Subject: Re: Hot Standby DBMS's
  5. Sender: news@cupnews0.cup.hp.com
  6. Message-ID: <BtCM7B.FyG@cup.hp.com>
  7. Date: Fri, 21 Aug 1992 19:30:47 GMT
  8. References: <BtB5us.MsD@world.std.com>
  9. Organization: Hewlett-Packard
  10. X-Newsreader: Tin 1.1scd1 PL4
  11. Lines: 26
  12.  
  13. From: edwards@world.std.com (Jonathan Edwards)
  14.  
  15. >>Since all locks need to be obtained on both systems before the 
  16. >>transaction is eventually committed, lock race conditions (defective
  17. >>design) result in deadlocks.  The system as a whole remains perfectly 
  18. >>serialized.
  19.  
  20. >Lock races are inherent functionally: what happens when two operators want
  21. >to update the same record.
  22.  
  23. While a race in one sense, this is a benign race unlike the disruptive
  24. race described by:
  25.  
  26. >My point is that the winner will not necessarily be the same on a 
  27. >system recieving a copy of the input stream.
  28.  
  29. If so, your transactions will deadlock, and will not complete. In the
  30. system described, all locks must be obtained on all systems before the 
  31. transaction can complete.  The locking behavior is that of two unrelated
  32. databases.  This is not a claim that there is no problem here: the races 
  33. must be prevented in order to do any work, a well known problem in
  34. transactional application design.  But that inability to do work is 
  35. the penalty of screwing up, rather than an out-of-sync copy of the 
  36. database or some other manifestation of non-serialized behavior.
  37.  
  38. Dan Hepner
  39.