On Tue, Apr 3, 2012 at 3:53 PM, Simon Slavin <slav...@bigfraud.org> wrote:
>
> On 3 Apr 2012, at 9:53am, Dan Kennedy <danielk1...@gmail.com> wrote:
>
>> As Jay says, deadlock is not possible for implicit transactions.
>> SQLite will keep retrying until either your busy-handler returns
>> zero (if you configured a busy-handler) or the timeout is reached
>> (if you configured a timeout). It sounds like the latter in this
>> case.
>
> You seem to have a setup where your failures can be produced on demand,
> albeit at random. So you can test whether this is a timeout-related problem
> but varying your timeout. Run it, and log how many failures you get. Then
> multiply (or divide) your timeout setting by ten and run it again. If you
> get failures at the same interval, it's not a timeout-related problem.
I've managed to make *something* reproducible. Take a look at the
following Python code, I hope it is self-explanatory:
------
import os
import sys
import apsw
import multiprocessing as mp
BUSYTIMEOUT = 5000
NPROCS = 4
def rmdb():
try:
os.remove('file.db')
os.remove('file.db-wal')
os.remove('file.db-shm')
except:
pass
def child():
try:
db = apsw.Connection('file.db')
db.setbusytimeout(BUSYTIMEOUT)
try:
db.cursor().execute('PRAGMA JOURNAL_MODE=WAL')
except:
print >>sys.stderr, "Error with PRAGMA:", sys.exc_info()[0]
db.close()
except:
print >>sys.stderr, "Unexpected error:", sys.exc_info()[0]
if __name__ == '__main__':
while True:
rmdb()
ps = [mp.Process(target=child) for i in xrange(NPROCS)]
for p in ps:
p.daemon = True
for p in ps:
p.start()
for p in ps:
p.join()
------
It reliably results in the "deadlock" scenario described above; hence
SQLite returns _BUSY for "PRAGMA" despite the big timeout (timeout
value seems to have no effect).
Can you please describe why SQLite does not retries the implicit
"PRAGMA" transaction here?
Gregory
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
