home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / database / 6436 < prev    next >
Encoding:
Text File  |  1992-08-30  |  2.1 KB  |  60 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: <BtruMB.Lt5@cup.hp.com>
  7. Date: Sun, 30 Aug 1992 00:56:35 GMT
  8. References: <RCBC.92Aug26125402@fafnir.cs.cornell.edu>
  9. Organization: Hewlett-Packard
  10. X-Newsreader: Tin 1.1scd1 PL4
  11. Lines: 47
  12.  
  13. From: rcbc@fafnir.cs.cornell.edu (Robert Cooper)
  14.  
  15. >Let's say we are updating bank account A at the primary and backup.
  16. >I was envisaging something like this:
  17.  
  18.  [totally parallel execution at the replicates, yielding Wrong Answer]
  19.  
  20. >Instead we could do this:
  21.  [do primary, then secondary, yielding correct answer]
  22.  
  23. >I presume this is Dan Hepner's point, and he's right. Distributed nested
  24. >transaction systems look like they will allow people to program this
  25. >solution. My only comment would be that this doesn't look much easier than
  26. >the solutions people are coming up with using Isis and non-distributed
  27. >transactions. 
  28.  
  29. Shall we agree that there would be ample opportunity for optimization,
  30. including perhaps the most important, making it transparent to the
  31. application programmer?
  32.  
  33. In any case, the difference, as compared to the Isis approach is that
  34. this does in fact guarantee perfect synchronization.  This is not
  35. in any sense a claim that most people would find the Isis-style solution
  36. inadequate based solely on this criterion.
  37.  
  38. >Has anyone actually implemented a primary-backup database using distributed
  39. >transactions in this way? Are nested transactions (or at least some
  40. >conditional commit mechanism) part of Tuxedo, Encina, etc?
  41. >       -- Robert
  42.  
  43. Encina supports nested transactions, Tuxedo does not (at last check), 
  44. no common DBMS products do.  However:
  45.  
  46. Why do you believe nested transactions necessary?  Simplistically,
  47. your example could be reworded:
  48.  
  49.      transaction begin
  50.      send input to primary
  51.      if (success)
  52.        send input to replicate
  53.        if (success)
  54.          transaction commit
  55.      else abort
  56.  
  57. Not a nested transaction in sight. 
  58.  
  59. Dan Hepner
  60.