> But both "single writer" and “multiple readers" remain true regardless of the > journal mode in use. And the same isolation semantics are provided either > way, no?
It remains true, but I’m not sure if it's useful to understand isolation. I think isolation could be understood from multiple ‘useful’[1] perspectives. From a user’s perspective, the behaviour of the system is equivalent to some serial execution of transactions, giving the appearance that one transaction ran to completion before the next started. Working around the lack of this guarantee might be hard for programmers, and it’s useful to understand that the guarantee exists. This perspective is probably common to all databases which supports serializable isolation. From an operational perspective, which describes algorithms used and implementation details. I think it’s useful to understand algorithms because different algorithms give rise to different `busy` scenarios, and having a better mental model of algorithm helps reason about some of these scenarios. I’m not sure if the ’single writer’, ‘multiple reader’ abstraction gives insight into this perspective. A weaker model might end up confusing the user, if he ends up in a scenario which he doesn’t understand. There’s also a mathematical perspective, which involves(I think) proving that any legal history an algorithm produces is isolated. Rahul -------- [1]: Ref: Transaction Processing Concepts and Techniques - Jim Gray _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
