[sqlite] Statistical SQLITE_BUSY_SNAPSHOT in WAL mode
On 1 Jun 2015, at 7:05am, Dan Kennedy wrote: > On 05/31/2015 04:11 AM, Simon Slavin wrote: >> On 30 May 2015, at 9:59pm, Samuel Tebeka wrote: >> >>> I'm doing a BEGIN EXCLUSIVE before every write statement already, should I >>> do it for read steatements as well? >> It's worth a try. I'm not sure what's wrong here, I'm just hoping we find a >> way to change what's happening enough to figure out a good solution. > > SQLITE_BUSY_SNAPSHOT indicates that a connection is trying to upgrade a > read-transaction to read/write, but that the database has been modified since > the read transaction was opened and it is not possible to do so. That's why I recommended BEGIN EXCLUSIVE, guessing that nothing could stop an exclusive lock being upgraded. But I might be wrong. Simon.
[sqlite] Statistical SQLITE_BUSY_SNAPSHOT in WAL mode
On 05/31/2015 04:11 AM, Simon Slavin wrote: > On 30 May 2015, at 9:59pm, Samuel Tebeka wrote: > >> I'm doing a BEGIN EXCLUSIVE before every write statement already, should I >> do it for read steatements as well? > It's worth a try. I'm not sure what's wrong here, I'm just hoping we find a > way to change what's happening enough to figure out a good solution. SQLITE_BUSY_SNAPSHOT indicates that a connection is trying to upgrade a read-transaction to read/write, but that the database has been modified since the read transaction was opened and it is not possible to do so. https://www.sqlite.org/rescode.html#busy_snapshot
[sqlite] Statistical SQLITE_BUSY_SNAPSHOT in WAL mode
I'm doing a BEGIN EXCLUSIVE before every write statement already, should I do it for read steatements as well? -Original Message- From: sqlite-users-boun...@mailinglists.sqlite.org [mailto:sqlite-users-bounces at mailinglists.sqlite.org] On Behalf Of Simon Slavin Sent: Saturday, May 30, 2015 11:57 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] Statistical SQLITE_BUSY_SNAPSHOT in WAL mode On 30 May 2015, at 9:41pm, Samuel Tebeka wrote: > This is the official doc: > > 1.Process A starts a read transaction on the database and does one or > more SELECT statement. Process A keeps the transaction open. > 2.Process B updates the database, changing values previous read by > process A. > 3.Process A now tries to write to the database. But process A's view > of the database content is now obsolete because process B has modified > the database file after process A read from it. Hence process B gets > an SQLITE_BUSY_SNAPSHOT error. > > Do you have a recommendation about how to resolve this issue? Around the commands which read and write to the database, try executing BEGIN EXCLUSIVE the command END This should mean that the errors go away but it might slow down your programs unacceptably. Please tell us what happens. Simon. ___ sqlite-users mailing list sqlite-users at mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Statistical SQLITE_BUSY_SNAPSHOT in WAL mode
Hello, I recently decided to make my application use WAL mode since it works with multiple connections from multiple threads and It should improve performance. Since then, I have been having random SQLITE_BUSY_SNAPSHOTS errors (517). I read the documentation and tried to debug the code but it seems to occur in a different situation and different thread every time. (I have 10+ threads who can open a connection at any time). This is the official doc: 1. Process A starts a read transaction on the database and does one or more SELECT statement. Process A keeps the transaction open. 2. Process B updates the database, changing values previous read by process A. 3. Process A now tries to write to the database. But process A's view of the database content is now obsolete because process B has modified the database file after process A read from it. Hence process B gets an SQLITE_BUSY_SNAPSHOT error. Do you have a recommendation about how to resolve this issue? Is there some kind of debug mode where I can see exactly which thread is A and which is B? (the one throwing the error is A, but how can I know who is B?) Any workaround? Thanks. Samuel.
[sqlite] Statistical SQLITE_BUSY_SNAPSHOT in WAL mode
On 30 May 2015, at 9:59pm, Samuel Tebeka wrote: > I'm doing a BEGIN EXCLUSIVE before every write statement already, should I > do it for read steatements as well? It's worth a try. I'm not sure what's wrong here, I'm just hoping we find a way to change what's happening enough to figure out a good solution. Simon.
[sqlite] Statistical SQLITE_BUSY_SNAPSHOT in WAL mode
On 30 May 2015, at 9:41pm, Samuel Tebeka wrote: > This is the official doc: > > 1.Process A starts a read transaction on the database and does one or > more SELECT statement. Process A keeps the transaction open. > 2.Process B updates the database, changing values previous read by > process A. > 3.Process A now tries to write to the database. But process A's view > of the database content is now obsolete because process B has modified the > database file after process A read from it. Hence process B gets an > SQLITE_BUSY_SNAPSHOT error. > > Do you have a recommendation about how to resolve this issue? Around the commands which read and write to the database, try executing BEGIN EXCLUSIVE the command END This should mean that the errors go away but it might slow down your programs unacceptably. Please tell us what happens. Simon.
