home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / mswindo / misc / 2105 < prev    next >
Encoding:
Text File  |  1992-08-17  |  2.7 KB  |  44 lines
  1. Newsgroups: comp.os.ms-windows.misc
  2. Path: sparky!uunet!mcsun!sunic!aun.uninett.no!ugle.unit.no!humpty.edb.tih.no!fiero.edb.tih.no!lumina.edb.tih.no!ketil
  3. From: ketil@edb.tih.no (Ketil Albertsen,TIH)
  4. Subject: Re: SMARTDRV for Windows 3.1
  5. Message-ID: <1992Aug17.121720.16873W@lumina.edb.tih.no>
  6. Sender: ketil@edb.tih.no (Ketil Albertsen,TIH)
  7. Organization: T I H / T I S I P 
  8. References: <1992Aug12.233533.8605@dmp.csiro.au> <BszDLM.G8u@fmsrl7.srl.ford.com>
  9. Posting-Front-End: Winix Conference v 92.05.15  1.20 (running under MS-Windows)
  10. Date: Mon, 17 Aug 1992 12:17:15 GMT
  11. Lines: 31
  12.  
  13. In article <BszDLM.G8u@fmsrl7.srl.ford.com>, vscarafi@eccdb1.pms.ford.com (Vincent F. Scarafino) writes:
  14.  
  15. >Programs that do proper transaction support *require* the assurance that at
  16. >least a minimal amount of data be safely written to a log (in such a way as
  17. >to survive the loss of power) *before* they can acknowledge to the application
  18. >that a transaction has been committed. Otherwise there is an integrity problem.  
  19.                                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  20. Well, isn't that a little pessimistic? A rollback is not an integrity problem,
  21. it is next to "normal" in DBMSs - at least you should be prepared for it. And
  22. you can make a perfectly consistent system with no integrity probles even if
  23. you have no guarantee that "at least a minimal amount of data" is written
  24. safely to disk. The last data you write to the log is the commit record, and
  25. if after a power loss you don't find a complete commit record in the log (you
  26. may end the record with a checksum to verify that it is complete), then you
  27. have a rollback condition. If you find a commit record, it might be the case
  28. that the user was not informed about the successful commit before power went
  29. off, but he did request a commit and thereby gave up his right to do a
  30. rollback. So the DBMS should insist that everything is consistent (which it is!).
  31.  
  32. The only thing you require is that when the disk system reports that the
  33. entire data record has been written successfully to disk, then it *is* written 
  34. successfully to disk. If a power loss occurs before this report is given, then
  35. it is not written successfully to disk, and everything is still consistent,
  36. although in the state of the database prior to transaction start. (Rollback)
  37.  
  38. A "nice" DBMS may after power up pick up the incomplete transaction and ask
  39. if the user wishes a redo attempt, up to the point of the last successfully
  40. written log record (again, checksumming may be used to verify that the log
  41. record is indeed successfully written in its entirety). But this is not 
  42. required for consistency, and all redoing is under the full integrity 
  43. constraints mechanisms of the DBMS.
  44.