#SQLITE DATABASE LOCKED CODE#

# Pretend we're already in an atomic block to bypass the code # Reset state when entering an outermost atomic block. Ĭonnection = transaction.get_connection(ing) # Decorator: or context manager: with atomic(.). # `using`, it's actually the function being decorated.Ī = transaction.Atomic(DEFAULT_DB_ALIAS, savepoint)(using) # Bare decorator: - although the first argument is called If you add the following to your project's _init_.py:įrom django.db import connection, DEFAULT_DB_ALIASĭef atomic(using=None, savepoint=True, immediate=False): This can be accomplished by monkey patching the atomic decorator / context manager to support an immediate argument. However, SOME atomic blocks (those containing select_for_update or update_or_create) when on sqlite and using threads / processes _could_ be immediate transactions without too great of an impact. I agree with the assessment that transforming all atomic blocks into immediate transactions would have a huge negative impact. Just a not for anyone who has this same problem and is looking for a solution. But even if it's decided that some config option would be good, it probably shouldn't be too hard to add? Or? (Of course, the lock timeout thing that's mentioned in the Django documentation can still happen if your transactions are too long-lived, but that's different.)Īnd I think that if you're using 'with transaction.atomic()' in the first place, then you most likely want to write to the database, in which case there's not much reason not to always grab the write lock right away. After all, if you're not holding the read lock when you try to grab the write lock, then this particular problem won't happen. That's what 'BEGIN IMMEDIATE', in the above patch, does. Grab the write lock immediately (like 'SELECT FOR UPDATE' would have, if SQLite had supported it).That works, but is somewhat unsatisfactory. That is, the app must retry the transaction until it commits. Treat the 'database is locked' as if it were a 'serialization error', which it kind of is.(Many answers on and such are essentially this.)

Don't use SQLite, or don't do concurrency. I can see three possible solutions to this problem: It only matters that they do a read before they do a write. The timeout mentioned in the Django documentation will have absolutely no effect on this, and it doesn't matter how short-lived your transactions are.

The thread that didn't get the write lock immediately gets a 'database is locked' error.

On the other hand, if you drop the read lock and then wait, then you lose the 'serializable' isolation guarantee that SQLite tries to give. If you wait while holding the read lock, then nobody will ever be able to acquire exclusive access to the database, and everything will just hang. Now, the designers of SQLite apparently realized that if you already have the read lock, then it's not a good idea to start a blocking wait on the write lock.

Unfortunately, only one thread can have the write lock.

#SQLITE DATABASE LOCKED UPDATE#

Next, update_or_create needs to do an INSERT or UPDATE (not important which), so the threads needs to upgrade the read locks to write locks.Both threads acquire a shared read lock, and so the SELECTs succeed for both threads. Normally, update_or_create would first do a 'SELECT FOR UPDATE', but SQLite doesn't support that, so a plain 'SELECT' is done.

The current transaction.atomic() implementation results in a 'BEGIN', which tells SQLite to start deferred transactions, i.e., to *not* acquire any locks before it has to.Suppose two threads or processes run such a transaction at exactly the same time (but with different keys, doesn't matter, SQLite locks the whole database anyway). Return _in_memory_db(ttings_dict)Įxplanation: Consider a type of transaction consisting of, for example, an update_or_create() call, which you run in a 'with transaction.atomic()' context. + self.cursor().execute('BEGIN IMMEDIATE') Staying in autocommit mode works around a bug of sqlite3 that breaks +++ -272,7 +272,7 class DatabaseWrapper(BaseDatabaseWrapper): But it's possible you want to add a config option, or an argument to transaction.atomic(), or something of the kind.ĭiff -git a/django/db/backends/sqlite3/base.py b/django/db/backends/sqlite3/base.py I'd like to propose a change like this, which I think would fix a class of SQLite 'database is locked' problems.

Sqlite database locked