home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / mswindo / misc / 2138 < prev    next >
Encoding:
Text File  |  1992-08-18  |  3.2 KB  |  57 lines
  1. Newsgroups: comp.os.ms-windows.misc
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!caen!destroyer!fmsrl7!eccdb1.pms.ford.com!vscarafi
  3. From: vscarafi@eccdb1.pms.ford.com (Vincent F. Scarafino)
  4. Subject: Re: SMARTDRV for Windows 3.1
  5. Message-ID: <Bt6Mrn.1rx@fmsrl7.srl.ford.com>
  6. Originator: news@pms001
  7. Sender: usenet@fmsrl7.srl.ford.com (0000-Admin(0000))
  8. Organization: Ford Motor Co.
  9. References: <1992Aug17.121720.16873W@lumina.edb.tih.no>
  10. Date: Tue, 18 Aug 1992 13:57:19 GMT
  11. Lines: 44
  12.  
  13. ketil@edb.tih.no (Ketil Albertsen,TIH) writes:
  14. > In article <BszDLM.G8u@fmsrl7.srl.ford.com>, vscarafi@eccdb1.pms.ford.com (Vincent F. Scarafino) writes:
  15. > 
  16. > >Programs that do proper transaction support *require* the assurance that at
  17. > >least a minimal amount of data be safely written to a log (in such a way as
  18. > >to survive the loss of power) *before* they can acknowledge to the application
  19. > >that a transaction has been committed. Otherwise there is an integrity problem.  
  20. >                                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  21. > Well, isn't that a little pessimistic? A rollback is not an integrity problem,
  22. > it is next to "normal" in DBMSs - at least you should be prepared for it. And
  23. > you can make a perfectly consistent system with no integrity probles even if
  24. > you have no guarantee that "at least a minimal amount of data" is written
  25. > safely to disk. The last data you write to the log is the commit record, and
  26. > if after a power loss you don't find a complete commit record in the log (you
  27. > may end the record with a checksum to verify that it is complete), then you
  28. > have a rollback condition. If you find a commit record, it might be the case
  29. > that the user was not informed about the successful commit before power went
  30. > off, but he did request a commit and thereby gave up his right to do a
  31. > rollback. So the DBMS should insist that everything is consistent (which it is!).
  32. > 
  33. > The only thing you require is that when the disk system reports that the
  34. > entire data record has been written successfully to disk, then it *is* written 
  35. > successfully to disk. If a power loss occurs before this report is given, then
  36. > it is not written successfully to disk, and everything is still consistent,
  37. > although in the state of the database prior to transaction start. (Rollback)
  38.  
  39. But with cached writes, these things happen asynchronously, so you have no
  40. guarantee that they'll make it to the disk in total, or in any kind of order
  41. that resembles the order they were written in.  It is possible to have info
  42. on the disk that reflects the partial update of multiple transactions, all
  43. in different phases of update and non complete.  There is no consistent point
  44. of reference. 
  45.  
  46. > A "nice" DBMS may after power up pick up the incomplete transaction and ask
  47. > if the user wishes a redo attempt, up to the point of the last successfully
  48. > written log record (again, checksumming may be used to verify that the log
  49. > record is indeed successfully written in its entirety). But this is not 
  50. > required for consistency, and all redoing is under the full integrity 
  51. > constraints mechanisms of the DBMS.
  52.  
  53. These designs assume the knowledge of completed, consistent writes, and that
  54. cannot be guaranteed with cached writes.
  55.  
  56. Vince
  57.