I have never run into this issue myself.
However, you do not specify the version or Platform (Windows XXXX, Linux XXXX
(plus distribution), Other (Apple iOS, MVS, BSD, etc).
Nor the version of CPython nor from whence it came (preloaded? version?
Downloaded and installed yourself? Built yourself?)
Nor the version of sqlite3 python interface (the one that came with something?
what thing?)
Nor the version of sqlite3 itself nor its origins (did it come with the
platform, did you built it yourself, did it come with CPython?)
There have been some issues in the past with some distributions of the sqlite3
engine on some platforms by some vendors wherein they did not enable build it
properly (without usleep support, for example) causing all sorts of weirdness.
There are quite a lot of places for things to go wrong.
That said, using APSW containing sqlite3 (built from the tip of the sqlite.org
source) on Windows 10 the builtin busywait works properly. I gave up on using
the sqlite3 python wrapper long ago -- however it appears to work properly too.
I simply run the standard sqlite3s command shell and lock the database (begin
immediate) and then fire up the python script in another window. To release
the lock one simply does a commit or rollback in the shell.
2018-04-27 10:23:27 PY2 [D:\]
>testwait
Connected in 0.0 seconds
Row(timeout=300000)
Row(timeout=300000)
2018-04-27 10:23:43.717000
Traceback (most recent call last):
File "D:\testwait.py", line 19, in <module>
db.cursor().execute('begin immediate;')
File "src/cursor.c", line 236, in resetcursor
apsw.BusyError: BusyError: database is locked
2018-04-27 10:29:12 PY2 [D:\] *** NOTE THE TIME COMPARED TO THE TIME PRINTED
AT THE START OF THE WAIT ***
>
>testwait
Connected in 0.0 seconds
(300000,)
(300000,)
2018-04-27 10:42:55.747000
Obtained lock in 12.0350000858 seconds
>testwait
Connected in 0.0 seconds
(300000,)
(300000,)
2018-04-27 10:44:00.859000
Obtained lock in 113.229000092 seconds
---- testwait.py ----
from __future__ import absolute_import, division, print_function
import datetime
import time
import apsw
import apswaddins
st = time.time()
db = apsw.Connection('test.db')
print('Connected in', time.time()-st, 'seconds')
for row in db.cursor().execute('pragma busy_timeout=300000; pragma
busy_timeout;'):
print(row)
st = time.time()
print(datetime.datetime.now().isoformat(' '))
db.cursor().execute('begin immediate;')
print('Obtained lock in', time.time()-st, 'seconds')
or using sqlite3
from __future__ import absolute_import, division, print_function
import datetime
import time
import sqlite3
st = time.time()
db = sqlite3.connect('test.db')
print('Connected in', time.time()-st, 'seconds')
for row in db.cursor().execute('pragma busy_timeout=300000;'):
print(row)
for row in db.cursor().execute('pragma busy_timeout;'):
print(row)
st = time.time()
print(datetime.datetime.now().isoformat(' '))
db.cursor().execute('begin immediate;')
print('Obtained lock in', time.time()-st, 'seconds')
---
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-dev [mailto:sqlite-dev-boun...@mailinglists.sqlite.org]
>On Behalf Of Brian Bouterse
>Sent: Friday, 27 April, 2018 09:33
>To: sqlite-...@mailinglists.sqlite.org
>Subject: [sqlite-dev] Timeout Not Working for Me
>
>I'm seeing some very strange behavior with our sqlite usage. I have 2
>processes. I know sqlite isn't for multiprocessing, but this a
>timeout issue not a multiprocessing issue. I have my code set the
>busy_timeout early in my connection to 300 seconds (way more than 5
>second default). I do this by running:
>
>cursor.execute('PRAGMA busy_timeout=300000;')
>
>
>I then verify that sqlite knows it's set by reading it back
>
>
>cursor.execute('PRAGMA busy_timeout;')
>
>cursor.fetchone() # this shows 300000, which tells me the setting was
>set and sqlite knows it
>
>
># symptom
>
>1. Have 2 processes connect to one sqlite db.
>2. Have the first one hold the write lock for > 5 seconds
>
>3. Have the second process try to issue a write
>
>4. Observe after 5 seconds the second process emits a Database is
>Locked error.
>
>5. Wonder why it didn't happen after 300 seconds.
>
>
># my debugging
>
>
>I don't yet have a minimal reproducer outside of Python and Django,
>but I've debugged all the way into sqlite. Here's why I think the
>issue is in sqlite. I debugged the Django code[0][1] and it is being
>passed to Python's connect method correctly. Python's connect method
>(C code [2]) also is doing it right. Finally, I also set it directly
>using a PRAGMA approach and I verify that sqlite itself tells you it
>knows its sets.
>
>
># questions
>
>
>What is the retry behavior specifically? I was reading the sqlite C
>code and I had some trouble understanding how often it is retrying
>and if it's capable of retrying for long periods of time.
>
>
>What do I need to do to get this working?
>
>
>[0]: https://docs.djangoproject.com/en/1.11/ref/databases/#database-
>is-locked-errors
><https://docs.djangoproject.com/en/1.11/ref/databases/#database-is-
>locked-errors>
>[1]:
>https://github.com/django/django/blob/1.11.12/django/db/backends/sqli
>te3/base.py#L177
><https://github.com/django/django/blob/1.11.12/django/db/backends/sql
>ite3/base.py#L177>
>[2]:
>https://github.com/python/cpython/blob/master/Modules/_sqlite/connect
>ion.c#L181
><https://github.com/python/cpython/blob/master/Modules/_sqlite/connec
>tion.c#L181>
>
>
>Thanks!
>Brian
>
>
>--
>
>Brian Bouterse
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
