Условия гонки в джанго

Django 1.4+ поддерживает select_for_update, в более ранних версиях вы могли выполнять необработанные SQL-запросы, например select ... for update, который в зависимости от базовой БД будет блокировать строку от любых обновлений, вы можете делать с этой строкой все, что хотите, до конца транзакции. например

from django.db import transaction

@transaction.commit_manually()
def add_points(request):
    user = User.objects.select_for_update().get(id=request.user.id)
    # you can go back at this point if something is not right 
    if user.points > 1000:
        # too many points
        return
    user.points += calculate_points(user)
    user.save()
    transaction.commit()

Начиная с Django 1.1 вы можете использовать выражения ORM F() для решения этой конкретной проблемы.

from django.db.models import F

user = request.user
user.points  = F('points') + calculate_points(user)
user.save()

Для более подробной информации смотрите документацию:

https://docs.djangoproject.com/en/1.8/ref/models/instances/#updating-attributes-based-on-existing-fields

https://docs.djangoproject.com/en/1.8/ref/models/expressions/#django.db.models.F

Блокировка базы данных — это то, что нужно. Планируется добавить в Django поддержку «выбрать для обновления» (здесь), но пока самым простым было бы использовать необработанный SQL для ОБНОВЛЕНИЯ объекта пользователя, прежде чем вы начнете вычислять счет.

Пессимистическая блокировка теперь поддерживается ORM Django 1.4, если базовая БД (например, Postgres) поддерживает ее. См. примечания к выпуску Django 1.4a1. .

У вас есть много способов однопоточности такого рода.

Одним из стандартных подходов является Обновить сначала. Вы выполняете обновление, которое захватывает монопольную блокировку строки; затем делайте свою работу; и, наконец, зафиксируйте изменение. Чтобы это работало, вам нужно обойти кэширование ORM.

Другой стандартный подход заключается в наличии отдельного однопоточного сервера приложений, который изолирует веб-транзакции от сложных вычислений.

• Ваше веб-приложение может создать очередь запросов на оценку, запустить отдельный процесс, а затем записать запросы на оценку в эту очередь. Спаун можно поместить в urls.py Django, чтобы это происходило при запуске веб-приложения. Или его можно поместить в отдельный manage.py скрипт администратора. Или это можно сделать «по мере необходимости» при попытке первого запроса на оценку.

• Вы также можете создать отдельный веб-сервер со вкусом WSGI, используя Werkzeug, который принимает запросы WS через urllib2. Если у вас есть один номер порта для этого сервера, запросы ставятся в очередь TCP/IP. Если ваш обработчик WSGI имеет один поток, значит, вы достигли сериализованной однопоточности. Это немного более масштабируемо, поскольку механизм оценки представляет собой запрос WS и может запускаться где угодно.

Еще один подход заключается в том, чтобы иметь какой-то другой ресурс, который необходимо приобрести и удерживать для выполнения расчетов.

• Объект Singleton в базе данных. Одна строка в уникальной таблице может быть обновлена ​​с помощью идентификатора сеанса, чтобы захватить контроль; обновить с идентификатором сеанса None, чтобы освободить управление. Важное обновление должно включать фильтр WHERE SESSION_ID IS NONE, чтобы гарантировать, что обновление не будет выполнено, когда блокировка удерживается кем-то другим. Это интересно, потому что по своей сути это не гонка — это одно обновление, а не последовательность SELECT-UPDATE.

• Стандартный семафор можно использовать вне базы данных. С очередями (как правило) работать легче, чем с низкоуровневым семафором.

Возможно, это слишком упрощает вашу ситуацию, но как насчет замены ссылки на JavaScript? Другими словами, когда пользователь щелкает ссылку или кнопку, оборачивайте запрос в функцию JavaScript, которая немедленно отключает / «закрашивает» ссылку и заменяет текст информацией «Загрузка ...» или «Отправка запроса ...» или что-то в этом роде. похожий. Это сработает для вас?

Теперь вы должны использовать:

Model.objects.select_for_update().get(foo=bar)