Пессимистический и оптимистичный параллелизм (блокировка и обратная связь)
Я создаю приложение по следующим критериям:
- рабочие элементы: элементы, которые должны обрабатываться пользователями вручную через Интернет (короткая одностраничная форма)
- Несколько пользователей, работающих "рабочие элементы"
- У каждого пользователя есть очередь "рабочих элементов"
- Существует поиск, который позволяет пользователям просматривать "рабочие элементы" и назначать "рабочие элементы" своим очередям.
- Пользователи могут извлекать "рабочие элементы" из очередей других людей, назначая их себе
Примечание: "рабочие элементы" обрабатываются только один раз. Это не вики-страница, это скорее совместимое упражнение, которое должен выполнять только один пользователь. Как только "рабочий элемент" обработан, он исчезает из системы (за исключением некоторого аудита / отчетности), что-то вроде системы отслеживания ошибок
Какой вариант вы считаете лучшим? Можете ли вы привести какие-либо основные приложения, которые поддерживают ваше мнение?
Опция 1:
- Когда пользователь А просматривает или обрабатывает "рабочий элемент", "рабочий элемент" блокируется.
- Когда другие пользователи переходят к "рабочему элементу" после того, как пользователь А открывает "рабочий элемент", они могут видеть только "рабочий элемент". Они не могут писать.
- Срок действия блокировки истекает через n минут, после чего другой пользователь может заблокировать "рабочий элемент".
Вариант 2:
- Любой пользователь может открыть "рабочий элемент", не блокируя его.
- Если пользователь A работает с "рабочим элементом", отправив форму, а пользователь B работает с тем же "рабочим элементом", то работа пользователя A вступит в силу в базе данных, и пользователь B будет проинформирован о том, что его изменения не вступили в силу, поскольку другие Пользователь изменил "рабочий элемент".
Мне лично нравится вариант 2. Мысли, пожалуйста?
3 ответа
Похоже, вы говорите о пессимистичных стихах оптимистического управления параллелизмом.
Оба они широко используются, лично мне легче иметь дело с оптимистичным параллелизмом, но это будет зависеть от ваших собственных требований и использования. Если правки (и потенциальные конфликты) являются общими, то может быть целесообразным пессимистическое управление параллелизмом, если нет, то оптимистичный параллелизм будет работать быстрее и проще.
Дайте мне знать, если вы хотите увидеть примеры кода, использующие тип данных RowVersion в SQL Server (это то, что я сейчас использую), это довольно просто:
- Все таблицы включают столбец RowVersion
- Все запросы SELECT включают этот столбец (для данных, которые могут быть изменены)
- Все запросы UPDATE или DELETE включают WHERE RowVersion = @RowVersion. Это оптимистичная часть: если возвращено 0 строк, кто-то еще коснулся строки, обновление не происходит, поэтому сообщите об этом пользователю. ПРИМЕЧАНИЕ. Если строка была обновлена, то также должно быть возвращено новое значение для RowVersion. Это также относится и к запросам INSERT, так же, как вы бы возвращали идентификатор столбца идентификаторов после вставки.
Не уверен, как описать форму простыми терминами, но это не страница сообщества, а разовая вещь. Гипотетически, скажем, пользователь должен был сопоставить имя John DOEE с одним из следующих имен: John Doe Jon Do После того, как это сработает, редактирование завершено. В нашем случае нам не нужно было бы просто
Учитывая этот комментарий, я бы остановился на варианте 1. Учитывая, что эти изменения являются однократными, нет смысла разрешать нескольким людям работать над одним и тем же изменением. Ты только тратишь время второго человека.
Лично я бы выбрал вариант 2 - плюс, если там применимо (например, эти правки в более длинном тексте), возложить на пользователя B ответственность за объединение правок. Дайте B инструмент для этого.