home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / database / 6435 < prev    next >
Encoding:
Text File  |  1992-08-30  |  2.0 KB  |  49 lines
  1. Newsgroups: comp.databases
  2. Path: sparky!uunet!ulowell!news.bbn.com!usc!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: <BtruJB.Lrn@cup.hp.com>
  7. Date: Sun, 30 Aug 1992 00:54:47 GMT
  8. References: <CHRIS.92Aug28101634@yen.imsi.com>
  9. Organization: Hewlett-Packard
  10. X-Newsreader: Tin 1.1scd1 PL4
  11. Lines: 36
  12.  
  13. From: chris@yen.imsi.com (Chris Payne)
  14.  
  15. >   If this advice "credit must always precede debit" is not followed you 
  16. >   might get deadlocks even without replication.  However, this is 
  17. >   insufficient to prevent the other kind of out-of-order deadlocks.
  18.  
  19. >Here's the idea: serialize & fork the db request stream.  Each hot
  20. >standby database will receive the same transactions in the same order.
  21. >Other receiver(s) can take the same stream and keep it for posterity.
  22. [but ...]
  23.  
  24. We'll agree that your solution both solved the out-of-order lock problem, 
  25. but left an unusable solution due to performance considerations. 
  26. The problem is that you went way too far.  One need not serialize 
  27. the entire input stream.
  28.  
  29. >   >If you want to catch-up a server which is down periodically, keep a
  30. >   >copy of the request stream.
  31. >
  32. >   How would you guarantee that transactions will be executed in the same
  33. >   serial order as was implied by the online system?  As has been pointed
  34. >   out, such a guarantee is required to keep the copies synchronized.
  35. >
  36. >Unless you're worried about the non-serial nature of the server
  37. >itself, this is trivial, right?
  38. >/c (chris@imsi.com)
  39.  
  40. It's not trivial; while the transactions were of course executed in
  41. parallel, there is an "as if serialized" ordering which was achieved.
  42. We cannot know that ordering until after the fact, and even then the only 
  43. way we are likely to be able to figure it out is by examining proprietary
  44. log records. However, if we expect to keep two replicates perfectly 
  45. synchronized, this ordering must be exact on all replicates.  This
  46. generally precludes a solution based on a queued request stream.  
  47.  
  48. Dan Hepner
  49.