home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / database / 6637 < prev    next >
Encoding:
Internet Message Format  |  1992-09-09  |  2.3 KB
  1. Path: sparky!uunet!cs.utexas.edu!sun-barr!olivea!spool.mu.edu!nigel.msen.com!caen!sdd.hp.com!scd.hp.com!cupnews0.cup.hp.com!dhepner
  2. From: dhepner@cup.hp.com (Dan Hepner)
  3. Newsgroups: comp.databases
  4. Subject: Re: Hot Standby DBMS's
  5. Message-ID: <BuBnqw.DIw@cup.hp.com>
  6. Date: 9 Sep 92 17:40:07 GMT
  7. References: <1992Sep9.112749.11492@uk03.bull.co.uk>
  8. Sender: news@cupnews0.cup.hp.com
  9. Organization: Hewlett-Packard
  10. Lines: 43
  11. X-Newsreader: Tin 1.1scd1 PL4
  12.  
  13. From: dboyce@hemel.bull.co.uk (David Boyce)
  14.  
  15. >Obviously, any given DB vendor could (given sufficient justification)
  16. >implement their own RHS (Remote Hot Standby) DB.  This justification is
  17. >work for the marketeers, one of whom I am not.
  18. >
  19. >My argument proceeds on the assumption that such justification exists,
  20. >in order to establish the need for an 'open' RHS protocol standard.
  21.  
  22. Ok; let's grant that there is market demand for a remote hot standby
  23. configuration.
  24.  
  25. >Owing to the increase in customer interest and use of Distributed TP
  26. >systems (around Tuxedo, Encina etc.) it seems inevitable that DTP-RHS
  27. >combined functionality will become important for some customers.  These
  28. >are the people for whom 'such openness' is important.
  29.  
  30. The question remains, of what benefit is this openness?  Openness
  31. has three potential benefits: portability of programs, interoperability
  32. of programs, and interchangability of system components from different
  33. vendors.  None of the three are intuitively obvious as benefits in
  34. this situation.
  35.  
  36. We could also assume that a proprietary RHS could itself be XA compliant,
  37. capable of being part of a larger global transaction.
  38.  
  39. >Since the working of RHS is based around the ability to restart
  40. >transactions, the extention of this into DTP involves restarting
  41. >Distributed transactions.  This requires the cooperation of the
  42. >Transaction Manager - hence the need for an Open RHS protocol.
  43.  
  44. The DTP style RHS is indeed based on the ability to restart txns;
  45. the DBMS model need not be so based.
  46.  
  47. >DB vendors / Transaction Manager vendors which can offer such a
  48. >combination of functionality clearly have the edge in that segment of
  49. >the market which needs it investment).
  50. >David Boyce    (David.Boyce@hemel.bull.co.uk) 
  51.  
  52. But as yet we haven't uncovered any new functionality.  What we have
  53. are two ways of solving the same problem.
  54.  
  55. Dan Hepner
  56.