> 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 ar
> 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
> 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 ‘u
> I think "single writer, multiple readers" is the simplest way to describe
sqlite's approach to isolation
I’m not sure if this summarization paints enough of a picture about how SQLite
restricts interleaving of read & write operations between concurrent
transactions, to guarantee isolation. For
> There seems to be a few misconceptions in the article regarding the
> difference between DEFERRED/IMMEDIATE/EXCLUSIVE
Looks like I mistakes in the 2PL section, it had contradictory content about
`RESERVED` locks. Thanks for your feedback, have pushed corrections.
> Specifically, your diagrams
I wrote an article about my high-level understanding of `SQLITE_BUSY` errors,
hoping it might help others understand concurrency in SQLite better. It covers
scenarios under which the error shows up, while SQLite tries to respect its
isolation guarantee.
https://www.activesphere.com/blog/2018/12
6 matches
Mail list logo
