> All true. But why start with this scenario? While trying to explain operational aspects of SQLite’s isolation implementations, serial execution seemed like the easiest to start with. Figured it might be easy to grasp first, before looking at interleaved operations followed by complications around algorithms (deadlocks, stale snapshots). I read a book sometime back, which covered isolation in a similar way (serial, locks, optimistic) and remember liking the structure from a reader’s perspective.
> and as it is the first example it's likely that a new reader will > misinterpret this as describing the default mode of operation. I do mention when starting the section, that DEFERRED mode is default. > Having no readers and every connection explicitly opting in to > IMMEDIATE/EXCLUSIVE transactions is an unusual set of circumstances but the > article doesn't clarify this I also mention that starting all transactions this way might not be performant, and then start looking at DEFERRED mode. I’m not sure if it’s unusual or not, but in my case (see conclusion of article), I ended up using this method because it was easier to implement for my setup & the performance tradeoff was acceptable. Rahul _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
