Перестать перезаписывать друг друга - PullRequest
4 голосов
/ 22 февраля 2010

Я хочу, чтобы два пользователя случайно перезаписывали друг друга при обновлении записи. То есть два пользователя загружают страницу с записью А на ней. Пользователь один обновляет запись в AB, а пользователь два обновляет ее в AC.

Я не просто хочу, чтобы последний ударил базу данных, чтобы переопределить. Мне нужен механизм, чтобы сообщить, что запись была обновлена, поэтому ваша не может быть сохранена.

Теперь у меня есть две идеи - поставить отметки во времени и проверить это. Если это не совпадает, не позволяйте обновление. Второй способ - GUID записи каждый раз, когда выполняется обновление, проверьте GUID и, если он не совпадает, не обновляйте.

Является ли любой из этих методов допустимым, если это так, который является лучшим. Если нет, то что вы предлагаете. Это в C #, если это имеет значение

Спасибо

Ответы [ 6 ]

11 голосов
/ 22 февраля 2010

Два метода, которые вы упомянули, фактически эквивалентны - в любом случае вы получите уникальный идентификатор для «записи во время проверки». У меня нет какого-либо конкретного представления о том, что лучше, хотя временная метка, очевидно, дает вам дополнительное преимущество данных о том, когда запись была действительной.

Альтернативой является запоминание предыдущих значений и разрешение на обновление, только если они совпадают - таким образом, если пользователь A начал редактировать запись, тогда пользователь B входит и что-то меняет, а затем меняет обратно, пользователь A редактирует все еще действительны.

Термин для этих методов - оптимистическая блокировка (или оптимистический контроль параллелизма ).

5 голосов
/ 22 февраля 2010

Существует третий способ. Чтобы выполнить обновление, введите оператор обновления этой формы:

UPDATE table SET update_field = new_value
WHERE db_pk = my_pk       // assume primary key immutable
AND update_field = original_field_value

где original_field_value - значение поля до попытки обновления. Это обновление не будет выполнено, если кто-то еще изменил update_field, если только он не изменил его на то же значение, что и у вас.

4 голосов
/ 22 февраля 2010

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

См. ссылки здесь.

2 голосов
/ 22 февраля 2010

Любой метод действителен для проверки.

Что касается того, что лучше, вы должны смотреть на размер вашего приложения и сколько времени потребуется для реализации каждого из них. Так что, если это случится лишь случайно, я бы, возможно, выбрал более быстрое решение и реализовал опцию отметки времени.

Если вам нужен более подробный параллелизм Google - вот статья, с которой нужно начать - Concirrency

1 голос
/ 22 февраля 2010

Я использую первый вариант. Обновляйте отметку времени при каждом обновлении. Поэтому во время обновления мы проверяем равенство метки времени.

0 голосов
/ 22 февраля 2010

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...