home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / database / 6269 < prev    next >
Encoding:
Internet Message Format  |  1992-08-23  |  4.8 KB
  1. Path: sparky!uunet!decwrl!infopiz!lupine!motcsd!udc!mcdphx!ennews!anasaz!qip!briand
  2. Newsgroups: comp.databases
  3. Subject: Re: Hot Standby DBMS's
  4. Message-ID: <1992Aug23.031155.14761@anasaz>
  5. From: briand@anasaz (Brian Douglass)
  6. Date: 23 Aug 92 03:11:55 GMT
  7. References: <BtA7DE.JrG@world.std.com> <1992Aug21.073707.6235@anasaz> <BtDxM2.HJn@world.std.com>
  8. Organization: Anasazi, Inc.  Phoenix, Az
  9. Lines: 78
  10.  
  11. In article <BtDxM2.HJn@world.std.com> edwards@world.std.com (Jonathan Edwards) writes:
  12. >In article <1992Aug21.073707.6235@anasaz> briand@anasaz (Brian Douglass) writes:
  13. >>The two systems are not in lock step.  The above transaction would arrive
  14. >>at machine 1 as a DEPOSIT transaction and would be processed by the
  15. >>DEPOSIT process.  The very same transaction would be routed to machine 2
  16. >>for the same processing.  There is no need the individual DEPOSIT processes
  17. >>to even know about each other.  The coordination that does have to take
  18. >>place is that machine 2 completes the transaction successfully.  If it
  19. >>doesn't, then this transaction remains open in a log on machine 1.  It does
  20. >>NOT affect the consistency of the data on machine 1.  Machine 1 is just
  21. >>storing up transactions that are uncompleted on machine 2.  At this point
  22. >>it should be programatic to insure that when machine 2 does ressurect, it
  23. >>does catchup with machine 1, and all transactions are processed singularly
  24. >>by machine 2.
  25. >>
  26. >I am talking about inconsistency between the two databases, not within them.
  27. >It is an elementary fact that complex multithreaded systems are not
  28. >deterministic. Just reproducing the input-transaction stream on another
  29. >system will NOT GIVE YOU THE SAME RESULTS. I used the example of two operators
  30. >requesting an update on the same record. One wins, but not necessarily the
  31. >same one on both systems. Unless you add special application code to resolve
  32. >this, there will be an inconsistency between the databases. But hey, we don't
  33. >even need this. What about timestamps placed inthe database? These will be
  34. >different on the two systems, leading to inconsistencies (the two databases
  35. >are NOT EQUAL).
  36. >Duplexing inputs is simply not a general approach to data replication.
  37. >Thank you for your comments. Goodbye.
  38.  
  39. Testy? Tsk, tsk.  Back to the discussion.
  40.  
  41. In your example you talk of two operators updating the same record.  Fine,
  42. lets work with this. Take one person depositing to an account, another person
  43. debiting the same account.  If by chance the debit hits before the deposit,
  44. the average balance drops below a threshold and the account gets a service
  45. charge.  Not desired.  Obviously in the same system, if the deposit is first, 
  46. it obtains the locks on the records and commits its work first.  Then the 
  47. debit occurs.
  48.  
  49. No problems here.
  50.  
  51. So what do we do about remote backup?  Before the deposit releases its
  52. locks (commit) it dispatches the same transaction it just did to the remote
  53. system within a Remote transaction.  That is it goes to a transaction
  54. called Remote, who logs it, and once logged it informs the TM of its
  55. success.  With success, the deposit and the remote transactions are rolled
  56. forward, if not, they both get rolled back.  You could also make the call
  57. to the Remote transaction a Lazy commit, that is the deposit doesn't care
  58. (dangerous, but possible) what the result of the loggin is.  And now, with the 
  59. record unlocked, the debit transaction can proceed and repeat the Remote
  60. call.
  61.  
  62. The Remote transaction not only logs the transaction, but dispatches it to
  63. the remote system as an asynchronous call.  Once a reply of success is
  64. returned, the log is noted as to the success.  If failure, the item remains
  65. in an open state.  A watch deamon can keep track of the status of the
  66. remote system (which could be across the country or across the room), and
  67. can flag whether or not to dispatch qued transactions.
  68.  
  69. Although the application, DBMS and TM are multithreaded, all transactions
  70. do go through the TM and its Resource processes, and therefore can be
  71. controlled within a transactional statement.  In particular, the use of
  72. nested transactions and RPC (two strong points of Encina) make implementing
  73. this programmatic solution (yes, this does take special coding like Mr. Edwards 
  74. suggested) easier, but still within the DTP model.  With products like /Q for
  75. Tuxedo, you get a truer message passing approach to the replicated database
  76. issue.
  77.  
  78. I'm not saying this the best/only/ideal approach to a replicated
  79. database/high availability system, but it does work and with existing
  80. technology.  There's nothing exotic here.  
  81.  
  82. And I'll say it again.  Someday TMs and DBMS will give us this ability
  83. automatically, in the meantime, all solutions are welcome.
  84.  
  85. -- 
  86. "... For I have sworn upon the alter of god, eternal hostility against
  87. every form of tyranny over the mind of man."  Thomas Jefferson
  88. Brian Douglass        briand@anasazi.com     602-870-3330 X657
  89.