Re: [sqlite] SQLite error (5): database is locked

2019-02-04 Thread Simon Slavin 
On 4 Feb 2019, at 3:15pm, Urs Wagner  wrote:

> SQLite error (5): database is locked occurs?

Can't answer your question, but …

If you're getting unexpected locks, have you set a timeout on every connection 
to that database ?  That gets rid of most locks.

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite error (5): database is locked

2019-01-21 Thread Rowan Worth 
On Tue, 15 Jan 2019 at 02:54, Simon Slavin  wrote:

> The "just-in-time" idea mentioned in your question doesn't work in real
> life, since constantly checking mutex status keeps one core completely
> busy, using lots of power and generating lots of heat.
>

Technically "just-in-time" could be implemented fine; the normal file
locking primitives used on both windows and unix can operate in a blocking
mode, where the kernel wakes the process up once the lock has been
relinquished. sqlite just doesn't use that API.

It would be a pretty significant change for sqlite to invoke said API, and
may affect the ability to support other existing locking modes which don't
provide the same semantics and where polling _is_ required (eg. dotfile).

Also I'm not 100% sure whether it would be safe to drop in, or whether
blocking the process for lock acquisition within sqlite's locking protocol
would introduce deadlock scenarios.

FYI sqlite's backoff reaches a maximum sleep time of 100ms. Unless you're
on unix and compile without -DHAVE_USLEEP=1 in which case there's no
backoff and every sleep is 1000ms long.

-Rowan
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite error (5): database is locked

2019-01-14 Thread Simon Slavin 
On 14 Jan 2019, at 7:04pm, Tim Streater  wrote:

> Hmm, from my attempt at interpreting the source code I gained the impression 
> that the handler used exponential backoff for the first few attempts, but 
> then used a constant period for the rest (up to the set limit). Is this not 
> the case?

I'm sure your interpretation is correct.  I just knew that the default handler 
used exponential backoff, and what that means.  I didn't know that it used it 
for every retry.  It seems likely that the dev team set a maximum based on 
their understanding of what lock times were plausible.

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite error (5): database is locked

2019-01-14 Thread Tim Streater 
On 14 Jan 2019, at 18:54, Simon Slavin  wrote:

> SQLite's own busy_timeout routine (the one you get if you don't supply your
> own) uses exponential backoff. It first sleeps for a very small amount of
> time, then checks the lock. If access is still prevented it sleeps longer,
> then checks again. Then longer still, then longer still, until the amount of
> time /since the routine started/ exceeds the timeout you set.

Hmm, from my attempt at interpreting the source code I gained the impression 
that the handler used exponential backoff for the first few attempts, but then 
used a constant period for the rest (up to the set limit). Is this not the case?


-- 
Cheers  --  Tim
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite error (5): database is locked

2019-01-14 Thread Simon Slavin 
On 14 Jan 2019, at 6:34pm, Thomas Kurz  wrote:

>> pragma_busy_timeout
> 
> Does setting the busy_timeout retry periodically (e.g. every x milliseconds), 
> or is there some automatism that ensures that the requested operation is done 
> just-in-time as soon as the previous/blocking operation is finished?

The busy_timeout setting is the maximum amount of time that the busy_timeout 
routine is allowed to run.  That routine is not expected to sleep for that 
amount of time you set in a single sleep.

SQLite's own busy_timeout routine (the one you get if you don't supply your 
own) uses exponential backoff.  It first sleeps for a very small amount of 
time, then checks the lock.  If access is still prevented it sleeps longer, 
then checks again.  Then longer still, then longer still, until the amount of 
time /since the routine started/ exceeds the timeout you set.

The "just-in-time" idea mentioned in your question doesn't work in real life, 
since constantly checking mutex status keeps one core completely busy, using 
lots of power and generating lots of heat.

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite error (5): database is locked

2019-01-14 Thread Thomas Kurz 
> pragma_busy_timeout

Does setting the busy_timeout retry periodically (e.g. every x milliseconds), 
or is there some automatism that ensures that the requested operation is done 
just-in-time as soon as the previous/blocking operation is finished?

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite error (5): database is locked

2019-01-14 Thread Keith Medcalf 

Are you getting as OS ERROR 5 or the SQLITE Return Code 5 (SQLITE_BUSY).  

The former means that the OS is indicating that the USERID you are using to run 
the task cannot open the file or the directory or the temporary files or the 
journal files required because it has not been granted the necessary 
permissions to do so; the latter indicates that the file has been opened but 
that you simply are trying to do something while the database is busy doing 
something else.

---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

>-Original Message-
>From: sqlite-users [mailto:sqlite-users-
>boun...@mailinglists.sqlite.org] On Behalf Of Urs Wagner
>Sent: Monday, 14 January, 2019 02:24
>To: SQLite mailing list
>Subject: [sqlite] SQLite error (5): database is locked
>
>Hallo
>
>I use several tasks in C# to call Sqlite queries.
>No I get the error SQLite error (5): database is locked.
>Is it not possible to use more than one tasks with Sqlite?
>
>Regards
>
>Urs
>___
>sqlite-users mailing list
>sqlite-users@mailinglists.sqlite.org
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite error (5): database is locked

2019-01-14 Thread Simon Slavin 
On 14 Jan 2019, at 9:23am, Urs Wagner  wrote:

> I use several tasks in C# to call Sqlite queries.
> No I get the error SQLite error (5): database is locked.
> Is it not possible to use more than one tasks with Sqlite?

Please set a timeout for all connections to your database:





A good timeout value is at least 1 milliseconds.

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users