home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / database / 6245 < prev    next >
Encoding:
Internet Message Format  |  1992-08-21  |  2.7 KB
  1. Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!ames!agate!triplerock.CS.Berkeley.EDU!mao
  2. From: mao@triplerock.CS.Berkeley.EDU (Mike Olson)
  3. Newsgroups: comp.databases
  4. Subject: Re: distributed transactions
  5. Message-ID: <173oogINNmrp@agate.berkeley.edu>
  6. Date: 21 Aug 92 21:55:28 GMT
  7. References: <1736k9INNjhh@agate.berkeley.edu> <BtCrA6.Iuy@cup.hp.com>
  8. Organization: University of California at Berkeley
  9. Lines: 48
  10. NNTP-Posting-Host: triplerock.cs.berkeley.edu
  11.  
  12. In <BtCrA6.Iuy@cup.hp.com>, dhepner@cup.hp.com (Dan Hepner) asks for
  13. details on how non-blocking commit protocols handle network partitions:
  14.  
  15. > Maybe you can explain how this apparent dilemma is addressed:
  16. > 
  17. > Time 1:  node n acknowledges prepare
  18. > Time 2:  node n notes an inability to communicate with anyone else, in 
  19. >      particular any site capable of being the transaction coordinator
  20. > Time 3:  still no communications, patience exhausted at node n
  21.  
  22. here's what the distributed systems theorists say:  a partition splits
  23. a network into two pieces.  whichever piece contains a majority of
  24. the nodes in the original network may continue processing.  nodes in
  25. the minority clique cannot make further updates until the partition is
  26. repaired.
  27.  
  28. there are some obvious problems with this -- for example, if no clique
  29. contains a majority of the nodes in the original network, no one can
  30. make progress.
  31.  
  32. > On the other hand, the rarity of actual blockage makes extreme concern
  33. > not warranted for most real world systems.  The coordinator must go
  34. > away at precisely the right time, _and then never return_.  Surely some 
  35. > way needs to be offered to resolve the tie-up, but this issue does
  36. > not justify a fundamental complaint against distributed transactions.
  37.  
  38. partitions aren't that rare.  ethernet bridges go down all the time.
  39.  
  40. you're correct in your assertion that strong consistency in the face
  41. of catastrophic failures is very difficult to guarantee.  skeen's work
  42. makes it possible for some nodes, under some conditions, to continue
  43. to make progress when machines crash or communications fail, but it
  44. doesn't solve the whole problem.  other approaches are to relax your
  45. consistency requirements, or to have humans outside the loop grant
  46. permission to acquire locks and update tables during communications
  47. failures.
  48.  
  49. the added complexity of three-phase commit, coupled with the fact that
  50. a clever adversary can force blockage anyway, have meant that it hasn't
  51. gotten a lot of attention by commercial vendors.  in real life, what
  52. people do is spend a lot of money on redundant, highly reliable
  53. communications systems.  when something crashes, some expensive employees 
  54. get it working again fast.
  55.  
  56.                     mike olson
  57.                     project sequoia 2000
  58.                     uc berkeley
  59.                     mao@cs.berkeley.edu
  60.