home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / database / 6207 < prev    next >
Encoding:
Text File  |  1992-08-20  |  2.3 KB  |  48 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: <BtA7DE.JrG@world.std.com>
  6. Organization: The World Public Access UNIX, Brookline, MA
  7. References: <9208172103.AA04378@hplwk.hpl.hp.com> <Bt6IsC.F00@world.std.com> <1992Aug19.052516.24063@anasaz>
  8. Date: Thu, 20 Aug 1992 12:15:11 GMT
  9. Lines: 37
  10.  
  11. In article <1992Aug19.052516.24063@anasaz> briand@anasaz (Brian Douglass) writes:
  12. >Another approach to this through the use of Transaction Managers (Tuxedo,
  13. >Encina, Top-End under Unix).  These products, and their grandpappy, CICS,
  14. >have the ability to distribute transactions among processors or machines be
  15. >they 10 feet apart or 100 miles.  
  16. >
  17. >The general approach to your problem would be to have machine 1 (M1) receiving 
  18. >and processing transactions.  A 100 miles away, you put machine 2 (M2).  A 
  19. >wire runs between them.  Whenever a transaction comes into M1 for processing, 
  20. >the same transaction is forwarded on to M2 for identical processing.  If M1
  21. >goes down for some reason (Hurricane), M2 takes over processing.  Whether
  22. >transactions arrive at it from M1, or straight from the source units across
  23. >the net, they all look the same to it.  
  24.  
  25. I infer that you are using 'transaction processing' in the older usage, of
  26. a unit of work to be processed, canonically a 3270 screen. Nowadays a
  27. 'transaction manager' usually means a system to support logical database
  28. transactions with journaling and recovery, and does not refer to application
  29. data flow. The ENCINA product is only the former, as far as I know.
  30.  
  31. Given a CICS-like environment, you propose splitting all input transactions
  32. (3270 screens) across two systems (i infer). 
  33. One of these system is 'muted' so that its outputs are
  34. supressed. This is not quite perfect, though, due to the possibility of
  35. timing differences on the two systems. Any transaction mix that leads to
  36. lock races could have different outcomes on the two systems due to random
  37. timing differences.
  38.  
  39. It seems to me that you have to base hot standby either on a copy of the
  40. disk-write stream, or a copy of the journal stream, which is more efficient
  41. and can more easily support catchup. I am basically trying to
  42. find out if any commercial databases do replication based on the journal
  43. stream.
  44.  
  45.  
  46.  
  47.  
  48.