home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / database / 6227 < prev    next >
Encoding:
Internet Message Format  |  1992-08-20  |  1.4 KB
  1. Path: sparky!uunet!ogicse!decwrl!world!edwards
  2. From: edwards@world.std.com (Jonathan Edwards)
  3. Newsgroups: comp.databases
  4. Subject: Re: Hot Standby DBMS's
  5. Message-ID: <BtB5us.MsD@world.std.com>
  6. Date: 21 Aug 92 00:40:03 GMT
  7. Article-I.D.: world.BtB5us.MsD
  8. References: <BtA7DE.JrG@world.std.com> <BtAMG4.3rF@cup.hp.com>
  9. Organization: The World Public Access UNIX, Brookline, MA
  10. Lines: 21
  11.  
  12. In article <BtAMG4.3rF@cup.hp.com> dhepner@cup.hp.com (Dan Hepner) writes:
  13. >From: edwards@world.std.com (Jonathan Edwards)
  14. >
  15. >>Given a CICS-like environment, you propose splitting all input transactions
  16. >>(3270 screens) across two systems (i infer). 
  17. >>One of these system is 'muted' so that its outputs are
  18. >>supressed. This is not quite perfect, though, due to the possibility of
  19. >>timing differences on the two systems. Any transaction mix that leads to
  20. >>lock races could have different outcomes on the two systems due to random
  21. >>timing differences.
  22. >
  23. >Since all locks need to be obtained on both systems before the 
  24. >transaction is eventually committed, lock race conditions (defective
  25. >design) result in deadlocks.  The system as a whole remains perfectly 
  26. >serialized.
  27. >
  28. >Dan Hepner
  29.  
  30. Lock races are inherent functionally: what happens when two operators want
  31. to update the same record. My point is that the winner will not necessarily be
  32. the same on a system recieving a copy of the input stream.
  33.