Try studying basic database theory and technology to get a better understanding of the problem. You will then understand the reason for absolute transactional integrity and why Sqlite must use fsync or similar and expects fsync to be a complete implementation which ensures that each transaction is permanently stored once a COMMIT has succeeded. That ties the transaction rate to the physical rotation rate of the disk.
If you want Sqlite to be ACID your design needs to be centered around the disk you use since it is the absolute bottleneck. A 15,000 rpm disk will give you more than a 4,500 rpm one. Writing non-critical data to regular files or a non-ACID database will also up the throughput. From the early days of IT transaction processors have been used to ensure data integrity. An example is the development of CICS by IBM about 40 years or more ago. It made it possible to run important applications on computers without requiring some form of manual system to enforce integrity. Sqlite gives that capability to small distributed and embedded applications. > 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. > > 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
