многопроцессная задача Джанго

Question

У меня есть приложение django, работающее под lighttpd через fastcgi. Скрипт FCGI выглядит так:

python manage.py runfcgi socket=<path>/main.socket
    method=prefork \                                                                                                    
    pidfile=<path>/server.pid \                                                                                                                                        
    minspare=5 maxspare=10 maxchildren=10 maxrequests=500 \

Я использую SQLite. Итак, у меня 10 процессов, которые все работают с одной и той же БД. Далее у меня 2 просмотра:

def view1(request)
    ...
    obj = MyModel.objects.get_or_create(id=1)
    obj.param1 = <some value>
    obj.save ()

def view2(request)
    ...
    obj = MyModel.objects.get_or_create(id=1)
    obj.param2 = <some value>
    obj.save ()

И если эти представления выполняются в двух разных потоках, иногда я получаю экземпляр MyModel в БД с id = 1 и обновляю либо param1, либо param2 (НО не оба) - это зависит от того, какой процесс был первым. (конечно, в реальной жизни идентификатор меняется, но иногда два процесса выполняют эти два представления с одинаковым идентификатором)

Вопрос: что мне делать, чтобы получить экземпляр с обновленными param1 и param2? Мне нужно что-то для объединения изменений в разных процессах.

Одним из решений является создание объекта межпроцессной блокировки, но в этом случае я получу последовательности, выполняющие представления, и они не смогут выполняться одновременно, поэтому я прошу помощи

DUPE OF Джанго: Как я могу защитить от одновременного изменения записей базы данных

Answer 1

SQLite - не лучший выбор, если вам нужен такой параллельный доступ к базе данных. Я предлагаю перейти на некоторые другие rdbms, такие как MySQL или PostgreSQL, а также принять во внимание хрупкость get_or_create:

Как мне справиться с этим условием гонки в Джанго?

Что касается вышеуказанной ссылки, то существует и второе решение этой проблемы - использование уровня изоляции READ COMMITED вместо REPEATABLE READ. Но он менее проверен (по крайней мере, в MySQL), поэтому может быть больше ошибок / проблем с ним.