The issue has since been fixed somehow (after being outstanding for 6 years).
The Django docs gaslights the developer into thinking it's of some SQLite limitations:
"SQLite is meant to be a lightweight database, and thus can’t support a high level of concurrency. OperationalError: database is locked errors indicate that your application is experiencing more concurrency than sqlite can handle in default configuration."
But that's not true, the issue could be reproduced with just two "concurrent" connections given unfortunate timing.
Since I was stubborn enough to not switch to another database (for production loads) and I knew sqlite could handle loads of a couple requests per sec, I'm still salty that Django basically introduced random errors to a service I maintain just because they didn't want to fix the problem (and lied to me in the docs).
Interesting history on that ticket. Closed as "invalid" 7 years ago, reopened 10 months ago, and 6 months ago added as non-default option to git (but not released yet?).
I wonder what the downsides would be in enabling this by default. Would lit engthen the period of the write lock on the DB so this change could be a compatibility problem for existing systems?
If it's write heavy, and you need to use transactions for writes, you're screwed either way. (i.e. don't use sqlite)
If it's not write heavy, but you enabled `ATOMIC_REQUESTS = True` then all your requests will be serialized (which is obviously bad)
If your site does not write often and your reads don't require transactions, using BEGIN IMMEDIATE TRANSACTION is probably fine. Your transactional writes will still be serialized but if they don't happen often it's probably fine for a low/medium-low traffic site.
"If it's write heavy, and you need to use transactions for writes, you're screwed either way. (i.e. don't use sqlite)"
That depends on your definition of "write heavy". Given SQLite's performance I would expect anything below 1,000 writes a second to work just fine even with write locks, given moderately capable hardware.
https://code.djangoproject.com/ticket/29280
The issue has since been fixed somehow (after being outstanding for 6 years).
The Django docs gaslights the developer into thinking it's of some SQLite limitations:
But that's not true, the issue could be reproduced with just two "concurrent" connections given unfortunate timing.Since I was stubborn enough to not switch to another database (for production loads) and I knew sqlite could handle loads of a couple requests per sec, I'm still salty that Django basically introduced random errors to a service I maintain just because they didn't want to fix the problem (and lied to me in the docs).