home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / database / 6338 < prev    next >
Encoding:
Text File  |  1992-08-26  |  2.8 KB  |  77 lines
  1. Newsgroups: comp.databases
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!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.92Aug26125402@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 17:54:02 GMT
  12. Lines: 63
  13.  
  14. > >The latter approach has a number of tricky problems that people have
  15. > >pointed out. The main one is ensuring that concurrency control is
  16. > >coordinated between the replicated data managers so that exactly the same
  17. > >order of data updates and accesses occurs on both replicas.
  18. > 
  19. > Fine, but "coordination of concurrency control" is not required to 
  20. > achieve that goal if you use distributed transactions.  "Coordination 
  21. > of the input streams" may however be required to prevent deadlock 
  22. > causing race conditions.
  23.  
  24. Let's say we are updating bank account A at the primary and backup.
  25. I was envisaging something like this:
  26.  
  27.    top-level-trans
  28.       parallel begin
  29.          sub-trans-1
  30.             update A on server 1
  31.          end
  32.          sub-trans-2
  33.             update A on server 2
  34.          end
  35.       end
  36.    end
  37.  
  38. In which case we could not guarantee (without knowledge of the scheduling
  39. and concurrency control internal to server 1 and server 2) whether 
  40. the updates to A would be serialized identically at the two servers, given
  41. that other transactions might be simultaneously updating those account
  42. records, etc. We'd want to ensure that both subtransactions claimed the
  43. same locks in the same order with respect to competing transactions.
  44.  
  45. Instead we could do this:
  46.  
  47.    top-level-trans
  48.       serial-begin
  49.          sub-trans-1
  50.             update A on server 1
  51.          end
  52.    
  53.          sub-trans-2
  54.             apply results from sub-trans-1 to A on server 2
  55.          end
  56.       end
  57.    end
  58.  
  59. In this case we perform the logical operation on A at server 1, record the
  60. modified data items and apply those updates to server 2. Basically what
  61. this code is just a roundabout way of reading the journal from server 1 and
  62. applying the updates it records to server 2. 
  63.  
  64. I presume this is Dan Hepner's point, and he's right. Distributed nested
  65. transaction systems look like they will allow people to program this
  66. solution. My only comment would be that this doesn't look much easier than
  67. the solutions people are coming up with using Isis and non-distributed
  68. transactions. 
  69.  
  70. Has anyone actually implemented a primary-backup database using distributed
  71. transactions in this way? Are nested transactions (or at least some
  72. conditional commit mechanism) part of Tuxedo, Encina, etc?
  73.  
  74.        -- Robert
  75. --
  76. -- 
  77.