Re: [sqlite] Please explain multi-access behaviour to me

Andy Bennett, on Tuesday, June 18, 2019 03:53 PM, wrote... > > > Actually, you're better off setting a timeout rather than handling > > retry in your own code: > > > > > > As I understand it, SQLITE_BUSY can occur in two situations: one where > busy

Re: [sqlite] Please explain multi-access behaviour to me

Hi, Actually, you're better off setting a timeout rather than handling retry in your own code: As I understand it, SQLITE_BUSY can occur in two situations: one where busy looping will fix it and one where it won't. Using the busy_timeout handles

Re: [sqlite] Please explain multi-access behaviour to me

On 18 Jun 2019, at 2:11pm, Thomas Kurz wrote: > So have I understood correctly, that in an application, this kind of > SQLITE_BUSY handling is sufficient: > > BEGIN > UPDATE #1 > SELECT #2 > UPDATE #3 > COMMIT <- check for busy here and retry only the commit on failure I believe that the

Re: [sqlite] Please explain multi-access behaviour to me

te-users [mailto:sqlite-users- >boun...@mailinglists.sqlite.org] On Behalf Of Keith Medcalf >Sent: Tuesday, 18 June, 2019 08:25 >To: SQLite mailing list >Subject: Re: [sqlite] Please explain multi-access behaviour to me > > >On Tuesday, 18 June, 2019 07:12, Thomas Kurz >wrote:

Re: [sqlite] Please explain multi-access behaviour to me

On Tuesday, 18 June, 2019 07:12, Thomas Kurz wrote: >This has been a very informative and helpful discussion. Thank you. >So have I understood correctly, that in an application, this kind of >SQLITE_BUSY handling is sufficient: >BEGIN >UPDATE #1 >SELECT #2 >UPDATE #3 >COMMIT <- check for

Re: [sqlite] Please explain multi-access behaviour to me

This has been a very informative and helpful discussion. Thank you. So have I understood correctly, that in an application, this kind of SQLITE_BUSY handling is sufficient: BEGIN UPDATE #1 SELECT #2 UPDATE #3 COMMIT <- check for busy here and retry only the commit on failure And second,

Re: [sqlite] Please explain multi-access behaviour to me

On Monday, 17 June, 2019 21:36, Simon Slavin wrote: >I understand about the RESERVED lock. I read the documentation. My >surprise was at this, from further down the same page: >" No EXCLUSIVE lock is acquired until either the memory cache fills >up and must be spilled to disk or until the

Re: [sqlite] Please explain multi-access behaviour to me

On 6/17/2019 11:35 PM, Simon Slavin wrote: I suspect that a lot of software is using BEGIN when it should be using BEGIN EXCLUSIVE. A lot of software doesn't have persistent, long-lived reader transactions. If your readers come in, get their data, and quickly get out, then a writer has

Re: [sqlite] Please explain multi-access behaviour to me

On 18 Jun 2019, at 4:19am, Keith Medcalf wrote: > See https://sqlite.org/lockingv3.html > for how transactions and locks work in journal_mode=delete|persist|truncate > (ie, not WAL). > There is a link on that page to how transactions work when WAL is in effect. > > Note that the default

Re: [sqlite] Please explain multi-access behaviour to me

On Monday, 17 June, 2019 18:46, Simon Slavin wrote: >I think I see my error. I thought that the lock was promoted from >read to read/write when the INSERT command was processed. At this >point, SQLite knows that it is going to need to write. >Instead, although SQLite knows that it is going

Re: [sqlite] Please explain multi-access behaviour to me

On Monday, 17 June, 2019 18:46, Simon Slavin wrote: >I think I see my error. I thought that the lock was promoted from >read to read/write when the INSERT command was processed. At this >point, SQLite knows that it is going to need to write. >Instead, although SQLite knows that it is going

Re: [sqlite] Please explain multi-access behaviour to me

Hi, A connection doesn't need to check locks on every statement - only when it tries to spill to disk, most commonly during commit. I think I understand what you wrote. So the bit of my program can think that its changes were written to the database and only later might my program find

Re: [sqlite] Please explain multi-access behaviour to me

I think I see my error. I thought that the lock was promoted from read to read/write when the INSERT command was processed. At this point, SQLite knows that it is going to need to write. Instead, although SQLite knows that it is going to have to write, it does not try to promote the lock

Re: [sqlite] Please explain multi-access behaviour to me

>boun...@mailinglists.sqlite.org] On Behalf Of Igor Tandetnik >Sent: Monday, 17 June, 2019 18:28 >To: sqlite-users@mailinglists.sqlite.org >Subject: Re: [sqlite] Please explain multi-access behaviour to me > >On 6/17/2019 8:21 PM, Simon Slavin wrote: >> On 18 Jun 2019, at

Re: [sqlite] Please explain multi-access behaviour to me

On Monday, 17 June, 2019 17:50, Simon Slavin wrote: >Can someone please explain this error message to me: > >Simple database, journal mode set to 'delete', accessed by two >simultaneous sessions running the SQLite command-line shell, >SQLite version 3.28.0 2019-04-15 14:49:49 > >Session A: >

Re: [sqlite] Please explain multi-access behaviour to me

On 6/17/2019 8:21 PM, Simon Slavin wrote: On 18 Jun 2019, at 1:09am, Igor Tandetnik wrote: A connection doesn't need to check locks on every statement - only when it tries to spill to disk, most commonly during commit. I think I understand what you wrote. So the bit of my program can

Re: [sqlite] Please explain multi-access behaviour to me

On 18 Jun 2019, at 1:09am, Igor Tandetnik wrote: > A connection doesn't need to check locks on every statement - only when it > tries to spill to disk, most commonly during commit. I think I understand what you wrote. So the bit of my program can think that its changes were written to the

Re: [sqlite] Please explain multi-access behaviour to me

On 6/17/2019 7:49 PM, Simon Slavin wrote: Is session B complaining that session A has a lock ? Yes. If session A had a lock why was there no complaint for the INSERT ? A connection doesn't need to check locks on every statement - only when it tries to spill to disk, most commonly during

[sqlite] Please explain multi-access behaviour to me

Can someone please explain this error message to me: Simple database, journal mode set to 'delete', accessed by two simultaneous sessions running the SQLite command-line shell, SQLite version 3.28.0 2019-04-15 14:49:49 Session A: PRAGMA journal_mode; <-- says 'delete' CREATE TABLE