home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / database / 6234 < prev    next >
Encoding:
Text File  |  1992-08-21  |  1.1 KB  |  28 lines
  1. Newsgroups: comp.databases
  2. Path: sparky!uunet!decwrl!world!edwards
  3. From: edwards@world.std.com (Jonathan Edwards)
  4. Subject: Re: distributed transactions
  5. Message-ID: <BtC3E7.9yx@world.std.com>
  6. Organization: The World Public Access UNIX, Brookline, MA
  7. References: <9208210244.AA07031@hplwk.hpl.hp.com>
  8. Date: Fri, 21 Aug 1992 12:44:30 GMT
  9. Lines: 17
  10.  
  11. In article <9208210244.AA07031@hplwk.hpl.hp.com> albert@HPLWK.HPL.HP.COM (Joseph Albert) writes:
  12. >
  13. >If a non-blocking commit protocol is used, any transaction started at
  14. >a remote site which went down can be aborted, releasing its locks, and
  15. >leaving the database in a transaction-consistent state.
  16. >
  17. Could you site some references or examples for this statement?
  18. Certainly the conventional 2-phase commit protocol (which is what is
  19. implemented by all commercial instances of distributed TP that I know of)
  20. can easily leave you in a blocked-or-inconsistent state.
  21. See Bernstein and Goodman: Concurrency Control and Recovery in Database
  22. Systems. They state as a 'proposition' that any distributed transaction
  23. protocol has to be blocking in the presence of communication failures or
  24. total failures.
  25.  
  26.  
  27.  
  28.