Структура отслеживания изменений

Question

Мы стремимся реализовать оптимистическую блокировку в нашем приложении WCF / WPF. Пока что лучший способ, который я придумала, это реализовать универсальный Optimistic, который будет хранить копию оригинала и любые изменения (таким образом, он будет хранить две копии: оригинал и измененный) любого объекта значения, который может быть модифицирована. Это лучший способ сделать это?

Например: UserVO будет оборачиваться универсальным как Оптимистичный. При внесении изменений в Оптимистическое изменение будет внесено в измененную копию, хранящуюся в Оптимистике, в то время как оригинал, также сохраненный в Оптимистике, останется без изменений. Основная проблема заключается в том, что он будет использовать вдвое больше места и, следовательно, пропускную способность.

Спасибо

РЕДАКТИРОВАТЬ Решение должно быть независимым от базы данных, и было бы полезно иметь возможность указать политику разрешения конфликтов для каждого объекта значения. (Например, пользовательский объект может попытаться объединиться, если обновленные строки не были изменены, но объект транзакции всегда потребует вмешательства пользователя).

Answer 1

Одним из способов реализации логики оптимистической блокировки является ее основание на последней измененной временной метке строки. Поэтому обновление будет выглядеть следующим образом:

ОБНОВЛЕНИЕ .... ГДЕ id = x И last_updated = t

x: идентификатор записи. t: последняя обновленная временная метка строки, когда она была загружена из базы данных (т.е. до изменений).

Обратите внимание, что одним из полей, которые должны быть обновлены прямо или косвенно, является отметка времени, которая должна быть установлена ​​сейчас (или UtcNow).

Таким образом, обновление не будет выполнено, если запись была изменена в фоновом режиме. После сбоя обновления вы можете выполнить дополнительные запросы, чтобы определить причину сбоя. Например,

1. Запись была удалена.
2. Запись была изменена.

Этот простой подход обеспечивает оптимистическую блокировку на уровне строк, он не основан на столбцах и не имеет разрешения конфликтов.

Answer 2

Вы смотрели на Microsoft Sync Framework ?

Answer 3

Если вы используете сервер SQL, вы можете использовать столбец отметки времени. Столбец метки времени изменяется каждый раз, когда изменяется строка. По сути, когда вы обновляете БД, вы можете проверить, совпадает ли столбец отметки времени с моментом, когда клиент впервые получил данные, если так, то никто не изменил данные.

Редактировать

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

1. Клиент 1 запрашивает объект, сервер возвращает Объект V1
2. Клиент 2 запрашивает объект, сервер возвращает Object v2
3. Клиент 1 изменяет объект, отправляющий его обратно на сервер, как V1
4. Сервер сравнивает версию и видит v1 = v1, поэтому он фиксирует изменение
5. Сервер увеличивает версию объекта, поэтому теперь его v2
6. Клиент 2 модифицирует объект, отправляющий его обратно на сервер как v1
7. Сервер сравнивает версию и видит v1! = V2, чтобы он выполнял все ваши политики

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