Как реализовать оптимистическую блокировку кроме версии?

Реализация оптимистичной блокировки без использования версий

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

Основные альтернативные подходы

1. Контроль по полному состоянию объекта (State Comparison)

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

public class Product
{
    public int Id { get; set; }
    public string Name { get; set; }
    public decimal Price { get; set; }
    public int StockQuantity { get; set; }
    // Нет поля Version
}

public class OptimisticLockService
{
    public bool UpdateProduct(Product original, Product updated)
    {
        // Проверяем, что базовые поля не изменились
        var currentInDb = GetProductFromDb(original.Id);
        
        if (currentInDb.Name != original.Name ||
            currentInDb.Price != original.Price ||
            currentInDb.StockQuantity != original.StockQuantity)
        {
            // Обнаружен конфликт - данные были изменены другим процессом
            throw new OptimisticConcurrencyException("Product state has changed");
        }
        
        // Если проверка прошла, выполняем обновление
        SaveProductToDb(updated);
        return true;
    }
}

Преимущества: Не требует изменения модели данных. Недостатки: Сложнее реализация, возможны ложные конфликты при незначительных изменениях, высокие накладные расходы при многих полях.

2. Использование хэша или контрольной суммы (Hash/Checksum)

Генерируется хэш-сумма (например, SHA-256) от состояния объекта при чтении. При сохранении вычисляется хэш текущего состояния в БД и сравнивается с сохранённым.

public class Document
{
    public int Id { get; set; }
    public string Content { get; set; }
    public byte[] StateHash { get; set; } // Хэш состояния при последнем чтении
}

public void UpdateDocument(Document document)
{
    var currentHash = ComputeHash(document.Content);
    var dbDocument = GetDocument(document.Id);
    var dbCurrentHash = ComputeHash(dbDocument.Content);
    
    if (!dbDocument.StateHash.SequenceEqual(dbCurrentHash))
    {
        throw new OptimisticConcurrencyException("Document content modified concurrently");
    }
    
    // Обновляем документ и его хэш
    document.StateHash = currentHash;
    SaveDocument(document);
}

private byte[] ComputeHash(string content)
{
    using var sha256 = SHA256.Create();
    return sha256.ComputeHash(Encoding.UTF8.GetBytes(content));
}

Преимущества: Эффективно для больших объектов, хэш — компактное представление состояния. Недостатки: Дополнительные вычисления, необходимость хранить хэш.

3. Контроль по временным меткам (Timestamps without Version Field)

Использование существующих полей с временными метками, например CreatedAt или LastModifiedAt, как индикаторов изменений.

public class Order
{
    public int Id { get; set; }
    public string Status { get; set; }
    public DateTime LastModifiedAt { get; set; } // Существующее поле в модели
}

public bool TryUpdateOrder(Order order, DateTime originalLastModified)
{
    var currentOrder = GetOrder(order.Id);
    
    // Используем LastModifiedAt как аналог версии
    if (currentOrder.LastModifiedAt != originalLastModified)
    {
        return false; // Конфликт - порядок был изменен
    }
    
    order.LastModifiedAt = DateTime.UtcNow; // Обновляем метку времени
    SaveOrder(order);
    return true;
}

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

4. Натуральные ключи или комбинации полей (Natural Keys/Field Combinations)

Для некоторых сущностей уникальность определяется комбинацией полей (например, код + тип). Эта комбинация может служить для контроля изменений.

public class Configuration
{
    public string Code { get; set; }
    public string Environment { get; set; }
    public string Value { get; set; }
    // Уникальный ключ: комбинация Code + Environment
}

public void UpdateConfiguration(Configuration config, string originalValue)
{
    // Проверяем, что значение не изменилось с момента чтения
    var currentConfig = GetConfiguration(config.Code, config.Environment);
    
    if (currentConfig.Value != originalValue)
    {
        throw new OptimisticConcurrencyException("Configuration value changed");
    }
    
    SaveConfiguration(config);
}

Преимущества: Использует бизнес-логику модели. Недостатки: Применимо только к объектам с четкими натуральными ключами.

Практические рекомендации по реализации в C# Backend

• Использование паттерна Unit of Work: Централизовать проверку оптимистичных конфликтов в единой точке сохранения.
• Интеграция с Entity Framework Core: Реализовать через перехват операций SaveChanges.

public class OptimisticLockDbContext : DbContext
{
    public override int SaveChanges()
    {
        foreach (var entry in ChangeTracker.Entries())
        {
            if (entry.State == EntityState.Modified)
            {
                // Проверка конфликтов через хэш или сравнение полей
                var originalHash = entry.OriginalValues.GetValue<byte[]>("StateHash");
                var currentHash = ComputeHash(entry.Entity);
                if (!originalHash.SequenceEqual(currentHash))
                {
                    throw new DbUpdateConcurrencyException();
                }
            }
        }
        return base.SaveChanges();
    }
}

• Обработка конфликтов: Разработать стратегии разрешения — повторные попытки, merge-алгоритмы или пользовательский выбор.
• Производительность: Для больших объектов комбинировать методы — использовать хэш для основных полей.

Сравнение подходов

Выбор метода зависит от конкретной ситуации: если модель данных фиксирована — используйте State Comparison или Timestamps. Если допустимо расширение модели — Hash подход более эффективен. Для систем с высокой конкуренцией рекомендуется комбинация методов с четкой стратегией разрешения конфликтов.