home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / database / 6340 < prev    next >
Encoding:
Text File  |  1992-08-26  |  2.6 KB  |  55 lines
  1. Newsgroups: comp.databases
  2. Path: sparky!uunet!cs.utexas.edu!usc!rpi!batcomputer!cornell!fafnir!rcbc
  3. From: rcbc@fafnir.cs.cornell.edu (Robert Cooper)
  4. Subject: Re: Hot Standby DBMS's
  5. In-Reply-To: dhepner@cup.hp.com's message of Mon, 24 Aug 1992 18:49:29 GMT
  6. Message-ID: <RCBC.92Aug26130618@fafnir.cs.cornell.edu>
  7. Sender: rcbc@cs.cornell.edu (Robert Cooper)
  8. Reply-To: rcbc@cs.cornell.edu
  9. Organization: Cornell Univ. CS Dept, Ithaca NY 14853
  10. References: <RCBC.92Aug24122743@fafnir.cs.cornell.edu> <BtI4AH.D81@cup.hp.com>
  11. Date: Wed, 26 Aug 1992 18:06:18 GMT
  12. Lines: 41
  13.  
  14. > >Isis atomic multicast guarantees to deliver the messages in the same order
  15. > >at both primary and backup.
  16. > >        -- Robert Cooper
  17. > 
  18. > Does Isis guarantee atomic commit across both copies?
  19.  
  20. The "Atomic" in atomic multicast means:
  21.  
  22. (1) a total order on message delivery at all destinations. So if 
  23.     two clients send atomic broadcasts to a set of 3 servers, all servers
  24.     will see the two messages in the same (arbitrary) order. This ensures
  25.     coordinated input streams in the replicated DBs.
  26. (2) atomic delivery. Either all destinations will receive the message, or
  27.     none of them will. This handles cases where the sender fails part way
  28.     through sending the message, e.g. it broadcast the message, but one
  29.     recipient dropped it because of a buffer overrun and before the 
  30.     sender can retransmit, the sender crashes. Isis will make on of the other
  31.     recipients forward its copy of the message to the receiver that needs
  32.     it in this case.
  33.  
  34. So, no, it doesn't guarantee atomic commit. When Isis is treating the DBs
  35. as black boxes, you have to convince yourself that both DBs will carry out
  36. the same action (abort or commit) on the same input data. That's why we
  37. have to be very careful about the input stream the DBs see so that they
  38. really are deterministic. In the limit this means having the front end
  39. apply update transactions one-at-a-time and exclude read-only transactions
  40. while this is happening. Typically, in a controlled environment, and with
  41. application level knowledge about the transaction stream, we can make some
  42. valid assumptions about the DBs being deterministic. But not in the general
  43. case, which is why we don't try to package this up as a generic solution,
  44. but rather help the customer do this on a case-by-case basis. Or, in other
  45. cases the application can take explicit recovery if the one DB aborts and
  46. the other commits. 
  47.  
  48. We do have a general transaction tool in Isis that solves these problems by
  49. running a 2PC protocol with the DBs. Obviously in this case the DBs aren't
  50. black boxes. The X/Open standards in this area are very interesting to us.
  51.  
  52.         -- Robert
  53. --
  54. -- 
  55.