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

Question

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

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

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

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

Вариант 1:

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

Вариант 2:

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

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

Answer 1

Звучит так, как будто ты говоришь о пессимистичный стихи оптимистичный контроль параллелизма.

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

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

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

Answer 2

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

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

Answer 3

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