Re: [sqlite] unexpected sqlite_busy behaviour within transactions

2020-02-26 Thread Software
Dear Igor, Andy, Keith Thank you for your patience to explain. Now very clear to me why it is not worth for the second process to honor the sqlite_busy handler, and instead returns immediately. In retrospect re-reading with your explanations in mind, I also understand the official

Re: [sqlite] unexpected sqlite_busy behaviour within transactions

2020-02-22 Thread Keith Medcalf
On Saturday, 22 February, 2020 09:26, Andy Bennett wrote: >This other process has called "BEGIN IMMEDIATE TRANSACTION" and >https://sqlite.org/rescode.html#busy says >"The BEGIN IMMEDIATE command might itself return SQLITE_BUSY, but if it >succeeds, then SQLite guarantees that no subsequent

Re: [sqlite] unexpected sqlite_busy behaviour within transactions

2020-02-22 Thread Andy Bennett
Hi, A busy_timout is honored by write commands outside of transactions and by single write commands inside transactions, but not if preceded by a read command. I did not find this behaviour in the documentation, thus it might be a bug. It's documented in the description of

Re: [sqlite] unexpected sqlite_busy behaviour within transactions

2020-02-22 Thread Igor Tandetnik
On 2/22/2020 7:50 AM, softw...@quantentunnel.de wrote: A busy_timout is honored by write commands outside of transactions and by single write commands inside transactions, but not if preceded by a read command. I did not find this behaviour in the documentation, thus it might be a bug. It's

[sqlite] unexpected sqlite_busy behaviour within transactions

2020-02-22 Thread Software
Hi A busy_timout is honored by write commands outside of transactions and by single write commands inside transactions, but not if preceded by a read command. I did not find this behaviour in the documentation, thus it might be a bug. To reproduce (in a linux terminal): sqlite3 ~/test.db