home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / database / 6243 < prev    next >
Encoding:
Text File  |  1992-08-21  |  1.9 KB  |  45 lines
  1. Newsgroups: comp.databases
  2. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!sdd.hp.com!hpscdc!cupnews0.cup.hp.com!dhepner
  3. From: dhepner@cup.hp.com (Dan Hepner)
  4. Subject: Re: distributed transactions
  5. Sender: news@cupnews0.cup.hp.com
  6. Message-ID: <BtCrA6.Iuy@cup.hp.com>
  7. Date: Fri, 21 Aug 1992 21:20:30 GMT
  8. References: <1736k9INNjhh@agate.berkeley.edu>
  9. Organization: Hewlett-Packard
  10. X-Newsreader: Tin 1.1scd1 PL4
  11. Lines: 32
  12.  
  13. From: mao@triplerock.CS.Berkeley.EDU (Mike Olson)
  14.  
  15. >> > If a non-blocking commit protocol is used, any transaction started at
  16. >> > a remote site which went down can be aborted, releasing its locks, and
  17. >> > leaving the database in a transaction-consistent state.
  18. >>
  19. >> Could you site some references or examples for this statement?
  20.  
  21. >the basic strategy is to add phases to the 2-phase protocol and to use
  22. >message broadcast, so every site sees every message.  see
  23.  
  24. Maybe you can explain how this apparent dilemma is addressed:
  25.  
  26. Time 1:  node n acknowledges prepare
  27. Time 2:  node n notes an inability to communicate with anyone else, in 
  28.      particular any site capable of being the transaction coordinator
  29. Time 3:  still no communications, patience exhausted at node n
  30.  
  31. Non-blocking protocols seem all to substitute some other problem for
  32. the blocking problem.  Commonly, the above dilemma is addressed by 
  33. defining it away, declining to acknowledge that a node might lose all 
  34. communication.  Other writers have imagined it valuable to describe
  35. protocols which did not block, but were not guaranteed to get the
  36. right answer either.
  37.  
  38. On the other hand, the rarity of actual blockage makes extreme concern
  39. not warranted for most real world systems.  The coordinator must go
  40. away at precisely the right time, _and then never return_.  Surely some 
  41. way needs to be offered to resolve the tie-up, but this issue does
  42. not justify a fundamental complaint against distributed transactions.
  43.  
  44. Dan Hepner
  45.