Как лучше всего справиться с конфликтом параллелизма «многие ко многим»?

Question

У нас есть функция приложения, похожая на ярлыки gmail - вы можете «помечать» элементы.Теперь это параллельное приложение, т. Е. Так называемая «белая доска», которую могут редактировать несколько пользователей, а это означает, что многие пользователи могут выбрать повторное группирование элементов.В основном помечайте несколько элементов одновременно.

Определенно будут конфликты, но вопрос в том, как лучше всего с этим справиться?Единственная стратегия, которая приходит на ум, аналогична известному протоколу ALOHA, т. Е. Проверять перед фиксацией, если что-то изменилось, - если это так, прервать и сообщить пользователю;остальное совершить.Это довольно неэффективный IMO.

Вот две похожие идеи - одна сложная, а другая проще для сравнения:

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

Трудный: проверить, какие из них должны быть «удалены», т. е. могут быть некоторые, которые не относятся к категории (скажем, пользователем 2, т. е. пользователем 1 сделаноизменение и пользователь 2 также сделали это в то же время. По сути, поиск набора теговых элементов {user1 - user2}).Это будет чрезвычайно сложно и действительно не стоит затраченных усилий ИМХО.

Мне было интересно, какое наилучшее практическое решение использовать в таком случае, которое не мешает работе пользователя и не смущает их.

(Это приложение J2EE / Restlet с бэкэндом MySQL и интерфейсом Jquery / ajax)

Answer 1

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

Другое возможное решение будет похоже на # 2(просто перезаписывайте изменения по мере их появления), но сохраняйте ревизию каждого изменения, чтобы упростить возврат и сделать так, чтобы было легко определить, были ли изменения внесены поверх других.