home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / database / 6258 < prev    next >
Encoding:
Text File  |  1992-08-22  |  2.1 KB  |  40 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: <BtDxM2.HJn@world.std.com>
  6. Organization: The World Public Access UNIX, Brookline, MA
  7. References: <1992Aug19.052516.24063@anasaz> <BtA7DE.JrG@world.std.com> <1992Aug21.073707.6235@anasaz>
  8. Date: Sat, 22 Aug 1992 12:34:50 GMT
  9. Lines: 29
  10.  
  11. In article <1992Aug21.073707.6235@anasaz> briand@anasaz (Brian Douglass) writes:
  12. >The two systems are not in lock step.  The above transaction would arrive
  13. >at machine 1 as a DEPOSIT transaction and would be processed by the
  14. >DEPOSIT process.  The very same transaction would be routed to machine 2
  15. >for the same processing.  There is no need the individual DEPOSIT processes
  16. >to even know about each other.  The coordination that does have to take
  17. >place is that machine 2 completes the transaction successfully.  If it
  18. >doesn't, then this transaction remains open in a log on machine 1.  It does
  19. >NOT affect the consistency of the data on machine 1.  Machine 1 is just
  20. >storing up transactions that are uncompleted on machine 2.  At this point
  21. >it should be programatic to insure that when machine 2 does ressurect, it
  22. >does catchup with machine 1, and all transactions are processed singularly
  23. >by machine 2.
  24. >
  25. I am talking about inconsistency between the two databases, not within them.
  26. It is an elementary fact that complex multithreaded systems are not
  27. deterministic. Just reproducing the input-transaction stream on another
  28. system will NOT GIVE YOU THE SAME RESULTS. I used the example of two operators
  29. requesting an update on the same record. One wins, but not necessarily the
  30. same one on both systems. Unless you add special application code to resolve
  31. this, there will be an inconsistency between the databases. But hey, we don't
  32. even need this. What about timestamps placed inthe database? These will be
  33. different on the two systems, leading to inconsistencies (the two databases
  34. are NOT EQUAL).
  35. Duplexing inputs is simply not a general approach to data replication.
  36. Thank you for your comments. Goodbye.
  37.  
  38.  
  39.  
  40.