On Tue, 22 Jan 2019 at 17:24, Rahul Jayaraman <rahul.jayara...@hotmail.com> wrote:
> 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. > Of course - no four words are going to be able to communicate the subtlety of sqlite's locking protocol and the details of how it interacts with the different journal modes. But I maintain that "single writer multiple readers" is the simplest abstraction available to provide a solid foundation for unfamiliar readers; YMMV. I was also confused by this section of the article, the second sentence of which feels inconsistent and misleading: > NOTE: IMMEDIATE behaviour acquires a write lock which allows concurrent > readers, but blocks other concurrent writers (discussed further in Rollback > journal section). In the above case, since all transactions are started > with IMMEDIATE, they behave as writers, and concurrent transactions are > blocked thus enforcing serial execution. EXCLUSIVE behaviour acquires a > lock which blocks concurrent readers and writers. > 1. "In the above case, since all transactions are started with IMMEDIATE," -- the diagram is actually using EXCLUSIVE transactions not IMMEDIATE 2. "they behave as writers, and concurrent transactions are blocked" -- this implies to me that all transactions are blocked, and conflicts with the first sentence which says (correctly) that a write lock allows concurrent readers -Rowan _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
