Re: [sqlite] Feedback on article about SQLITE_BUSY

> 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

Re: [sqlite] Feedback on article about SQLITE_BUSY

On Fri, 25 Jan 2019 at 13:21, Rahul Jayaraman 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

Re: [sqlite] Feedback on article about SQLITE_BUSY

> 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

Re: [sqlite] Feedback on article about SQLITE_BUSY

On Tue, 22 Jan 2019 at 17:24, Rahul Jayaraman 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

Re: [sqlite] Feedback on article about SQLITE_BUSY

> 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

Re: [sqlite] Feedback on article about SQLITE_BUSY

On 22 Jan 2019, at 8:21am, Rowan Worth wrote: > Transactions cannot see > any updates which occur after they have begun, and writers are serialised. Simon. ___ sqlite-users mailing list

Re: [sqlite] Feedback on article about SQLITE_BUSY

On Tue, 22 Jan 2019 at 12:51, Rahul Jayaraman wrote: > > 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

Re: [sqlite] Feedback on article about SQLITE_BUSY

> 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.

Re: [sqlite] Feedback on article about SQLITE_BUSY

> 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

Re: [sqlite] Feedback on article about SQLITE_BUSY

There seems to be a few misconceptions in the article regarding the difference between DEFERRED/IMMEDIATE/EXCLUSIVE, and the fine details of how different lock states interact. Specifically, your diagrams suggest that once a writer obtains a RESERVED lock (as happens when an IMMEDIATE transaction

Re: [sqlite] Feedback on article about SQLITE_BUSY

> I have three points: Thank you, appreciate the feedback. I've updated the article with the changes you suggested. Rahul -- Sent from: http://sqlite.1065341.n5.nabble.com/ ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org

Re: [sqlite] Feedback on article about SQLITE_BUSY

On 8 Jan 2019, at 3:48pm, Rahul Jayaraman wrote: > https://www.activesphere.com/blog/2018/12/24/understanding-sqlite-busy > > I’d appreciate feedback on the article. I read your article, though I did not go through all the logic and check that it is correct. I like your choice of sections,

[sqlite] Feedback on article about SQLITE_BUSY

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.