Пессимистический и оптимистичный параллелизм (блокировка и обратная связь)

Question

Я создаю приложение по следующим критериям:

• рабочие элементы: элементы, которые пользователи должны обрабатывать вручную через Интернет (короткая одностраничная форма)
• Несколько пользователей, работающих «рабочие элементы»
• У каждого пользователя есть очередь «рабочих элементов»
• Существует поиск, который позволяет пользователям просматривать «рабочие элементы» и назначать «рабочие элементы» своим очередям
• Пользователи могут извлекать «рабочие элементы» из очередей других людей, назначая их себе

Примечание: «рабочие элементы» обрабатываются только один раз. Это не вики-страница, это скорее совместимое упражнение, которое должен выполнять только один пользователь. Как только «рабочий элемент» обработан, он исчезает из системы (за исключением некоторого аудита / отчетности), что-то вроде системы отслеживания ошибок

Какой вариант вы считаете лучшим? Можете ли вы привести какие-либо основные приложения, которые поддерживают ваше мнение?

Вариант 1:

• Когда пользователь А просматривает или обрабатывает «рабочий элемент», «рабочий элемент» блокируется.
• Когда другие пользователи переходят к «рабочему элементу» после того, как пользователь А открывает «рабочий элемент», они могут видеть только «рабочий элемент». Они не могут писать.
• Срок действия блокировки истекает через n минут, после чего другой пользователь может заблокировать «рабочий элемент».

Вариант 2:

• Любой пользователь может открыть «рабочий элемент», не блокируя его.
• Если пользователь A работает с «рабочим элементом», отправив форму, а пользователь B работает с тем же «рабочим элементом», то работа пользователя A вступит в силу в базе данных, и пользователь B будет проинформирован о том, что его изменения не были приняты влияет, потому что другой пользователь изменил «рабочий элемент».

Мне лично нравится вариант 2. Мысли, пожалуйста?

Answer 1

Похоже, вы говорите о пессимистическом стихах оптимистическом управлении параллелизмом.

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

Дайте мне знать, если вы хотите увидеть примеры кода, использующие RowVersion тип данных в SQL Server (это то, что я сейчас использую), хотя это довольно просто:

• Все таблицы включают столбец RowVersion
• Все запросы SELECT включают этот столбец (для данных, которые могут быть изменены)
• Все запросы UPDATE или DELETE включают WHERE RowVersion = @RowVersion. Это оптимистичная часть: если возвращено 0 строк, кто-то еще коснулся строки, обновление не происходит, поэтому сообщите об этом пользователю. ПРИМЕЧАНИЕ. Если строка была обновлена, то также должно быть возвращено новое значение для RowVersion. Это также относится к запросам INSERT, так же, как вы возвращали бы идентификатор столбца идентификаторов после вставки.

Answer 2

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

С учетом этого комментария я бы остановился на варианте 1. Учитывая, что эти изменения являются однократными, нет смысла разрешать нескольким людям работать над одним и тем же изменением. Вы только тратите время второго человека.

Answer 3

Лично я бы выбрал вариант 2 - плюс, если там применимо (например, эти правки находятся в более длинном тексте), чтобы пользователь Б обязан объединить правки. Дайте B инструмент для этого.