> > On 31 May 2009, at 9:24pm, Jay A. Kreibich wrote: > >> The whole point of a transaction is that once it >> returns "success" on a commit, it is committed to permanent storage, >> no matter what -- including crashes, power failures, and other major >> problems. > > My impression is that COMMIT/ROLLBACK is for data integrity: don't > update the account balance if the transaction didn't work. That sort > of stuff. Not to deal with hardware failure.
do not mix sql COMMIT with hardware sync/commit functionality, the subject of the posts refer mainly to the fsync/commit issue on hardware level. You are right with the statements below but this is not the point here: The developers of sqlite put a major effort to make it practically impossible that sqlite will ever end up with a corrupt database even when considering a powerloss or OS crash. One issue here is the requirement to exactly know and define when data has reached the disk surface. To achieve this, sqlite relies on the correct low level implementation of the fsync functions. The goal can't be reached if these functions do not behave as originally expected by the sqlite developers and then sqlite behaves similar if the synchronous pragma is set to default OFF. It's nothing to complain against sqlite it is just something users should be aware off, imo. > > I think that these days your computer can never know when things that > reached permanent storage. Permanent storage is too far away, behind > too many levels of caching for the CPU to ever know about it. Your > CPU may be virtual. Your storage medium may be virtual: a disk image, > a RAID controller, emulated hardware, or something like that. If you > talk to a hard disk by IDE it will be using onboard caching and not > admitting it to the motherboard (most of them do this these days). > > Unless you're going to disable caching all the way down the line from > CPU to physical hard disk, you're never going to get any real idea of > what the hardware's doing. And if you did that it would low things > down too much anyway. Cached writes do a really good job of speeding > things up. > > Simon. > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
