On Fri, 25 Jan 2019 at 13:21, Rahul Jayaraman <rahul.jayara...@hotmail.com> wrote:
> > 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 > > In the context of enforcing serial execution, it doesn’t matter if all > transactions are started with `IMMEDIATE` or if all transactions are > started with `EXCLUSIVE`. When using these behaviours, locks are acquired > at the beginning of a transaction, and are retained till commit or abort. > In `BEGIN IMMEDIATE` mode, all transactions try to acquire `RESERVED` locks > at the beginning, meaning there are no readers. If one transaction > succeeds, other concurrent transactions get blocked. > All true. But why start with this scenario? 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 and as it is the first example it's likely that a new reader will misinterpret this as describing the default mode of operation. -Rowan _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
