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

Question

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

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

Благодаря

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

Answer 1

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

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

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

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

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

Answer 2

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

UPDATE .... WHERE ID = х и last_updated = т

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

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

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

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

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

Answer 3

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