retrying SQLITE_BUSY errors

[Jonathan Lundell]

SQLite reports certain retryable locking conflicts with SQLITE_BUSY errors. But pysqlite lumps SQLITE_BUSY in with a collection of other, mostly non-retryable, errors and raises OperationalError without putting the error code (SQLITE_BUSY) in the exception structure. As I read the code, anyway.

The exception does store the readable error string ("database is locked" in this case, at least in the latest version of SQLite), but it a bit of a hack to be identifying specific error codes by their readable messages.

What's the intention here? Or am I just missing something?

[Roger Binns]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 21/10/11 17:08, Jonathan Lundell wrote:
> What's the intention here? Or am I just missing something?

I can't speak for pysqlite, but I would advise that you should set the
busy timeout rather than manually retrying. It has an automatic backoff
until eventually hitting whatever timeout you set, and won't reacquire the
GIL so other threads can run.

Roger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk6iH7IACgkQmOOfHg372QQkOACg4mnToi0GwqGG5XBG8ogiQNvV
l/gAoMdeRgMuF79WbL6XLLgtV4Cfl9rM
=NMex
-----END PGP SIGNATURE-----

[Jonathan Lundell]

On Oct 21, 2011, at 6:43 PM, Roger Binns wrote:

> On 21/10/11 17:08, Jonathan Lundell wrote:
>> What's the intention here? Or am I just missing something?
>
> I can't speak for pysqlite, but I would advise that you should set the
> busy timeout rather than manually retrying. It has an automatic backoff
> until eventually hitting whatever timeout you set, and won't reacquire the
> GIL so other threads can run.

Thanks. I see that pysqlite sets a five-second busy timeout by default. That should suffice.

Still, it seems to me that it'd be a good thing to put the SQLite error code in the exception....