Управление совместным выполнением в модели Django
Я использовал turbogears и направляющие немного. Перед использованием направляющих я пытался использовать чаши Грааля, потому что я использовал отличный для моих сценариев. Grails был трудным опытом.
отличный стек вызовов трудно считать для небольшой программы, но когда Вы добавляете в нескольких тяжелых платформах веса, простая ошибка может привести к 100 с строк. В отличие от направляющих версия чаш Грааля, которую я использовал, не имела инструментов, чтобы помочь мне определить то, что было моим и что принадлежало платформе.
я в конечном счете переключился на использование веб-инструментария Google, так как мне действительно не была нужна база данных.
я думаю, что Grails и Groovy открывают перспективу, но пользовательский опыт работы с ними является громоздким в настоящее время (подарок, будучи прошлой пружиной).
1 ответ
Короткий ответ, это действительно не вопрос Django в том виде, в каком он был представлен.
Управление параллелизмом часто представляется как технический вопрос, но во многих отношениях это вопрос функциональных требований. Как вы хотите / хотите, чтобы ваше приложение работало? Пока мы не узнаем этого, будет сложно дать какой-либо совет, связанный с Django.
Но я чувствую себя бессвязной, так что поехали ...
Есть два вопроса, которые я задаю себе, когда сталкиваюсь с необходимостью контроля параллелизма:
- Насколько вероятно, что двум пользователям понадобится для одновременного изменения одной и той же записи?
- Каково влияние на пользователя, если его / ее изменения в записи будут потеряны?
Если вероятность коллизий относительно высока или последствия потери модификации серьезны, то, возможно, вы имеете дело с некоторой формой пессимистической блокировки. В пессимистической схеме каждый пользователь должен получить логическую блокировку перед открытием записи для модификации.
Пессимистическая блокировка сопряжена с большой сложностью. Вы должны синхронизировать доступ к блокировкам, учитывать отказоустойчивость, истечение срока блокировки, могут ли блокировки отменяться суперпользователями, могут ли пользователи видеть, у кого есть блокировка, и т. Д. И т. Д.
В Django это может быть реализовано с помощью отдельной Модель блокировки или какой-то внешний ключ «заблокировать пользователя» на заблокированной записи. Использование таблицы блокировок дает вам немного больше гибкости с точки зрения хранения, когда была получена блокировка, пользователя, заметок и т. Д. Если вам нужна общая таблица блокировок, которую можно использовать для блокировки любого типа записи, взгляните на фреймворк django.contrib.contenttypes , но это может быстро превратиться в синдром космонавта абстракции.
Если коллизии маловероятны или утраченные модификации тривиально воссоздаются, то функционально можно обойтись с помощью методов оптимистичного параллелизма. Этот прием прост и проще в применении. По сути, вы просто отслеживаете номер версии или отметку времени модификации и отклоняете любые модификации, которые вы определяете как неисправные.
С точки зрения функционального дизайна, вам нужно только учитывать, как эти одновременные ошибки модификации представляются вашим пользователям .
В терминах Django оптимистичное управление параллелизмом может быть реализовано путем переопределения метода сохранения в вашем классе модели ...
def save(self, *args, **kwargs):
if self.version != self.read_current_version():
raise ConcurrentModificationError('Ooops!!!!')
super(MyModel, self).save(*args, **kwargs)
И, конечно же, чтобы любой из этих механизмов параллелизма был надежным, вы должны учитывать управление транзакциями . Ни одна из этих моделей не работает полностью, если вы не можете гарантировать свойства ACID для своих транзакций.