Что такое оптимистическая блокировка и как её реализовать?

А, оптимистическая блокировка, ну это же классика, блядь! Представь себе: ты такой заходишь в бар, видишь на стойке последний круассан. Берёшь его в руки, смотришь — свежий, вроде никто не трогал. Идёшь к кассе, а там очередь дохуя. Ты стоишь, держишь этот круассан, мечтаешь о нём. Подходишь наконец, а кассирша тебе: «Извините, мужик, только что последний забрали». Вот это и есть конфликт версий, ёпта! Ты думал, что он твой, а пока ты в очереди стоял, его уже кто-то хуяк и съел.

Так вот, оптимистическая блокировка — это когда мы надеемся, что все адекватные и конфликтов не будет. Мы не вешаем замок на круассан, пока его разглядываем. Мы просто запоминаем, как он выглядел (версию). А когда уже платить, проверяем — а не поменялся ли он? Не надкусил ли его кто? Если всё ок — забираем. Если нет — получаем по ебалу в виде исключения.

Как это работает, если по-простому:

1. Читаем запись. Запоминаем, какая у неё версия. Допустим, Version = 5. Как серийный номер на круассане.
2. Ковыряем её у себя в коде. Меняем цену, название — что угодно.
3. Пытаемся сохранить. Говорим базе: «Слушай, дай-ка обновить запись с id=10, но ТОЛЬКО если её версия до сих пор 5, окей? И заодно версию увеличь до 6».
4. Ждём ответа. Если за это время другой чувак уже успел обновить эту запись (и версия стала 6), база тебе такой: «Не, братан, опоздал. Конфликт». И шлёт тебе DbUpdateConcurrencyException. Всё, пиздец твоим изменениям.

Как это впихнуть в код:

1. Сущность. Надо добавить поле для версии.

public class Product
{
    public int Id { get; set; }
    public string Name { get; set; }
    public decimal Price { get; set; }
    // Вариант для SQL Server — ставим [Timestamp], будет тип rowversion
    [Timestamp]
    public byte[] RowVersion { get; set; } // Автоматически меняется при каждом обновлении
    // Или для других баз можно просто int
    // public int Version { get; set; }
}

2. Обработка в EF Core. Вот тут вся магия и происходит. Пытаешься сохранить, а оно может и выстрелить.

try
{
    var product = await _context.Products.FindAsync(productId);
    product.Price = newPrice; // Твои дерзкие изменения
    // SaveChanges сам проверит RowVersion/Version в БД
    await _context.SaveChangesAsync();
    // Если дошло сюда — ты красава, конфликта не было.
}
catch (DbUpdateConcurrencyException ex) // А вот если поймал эту гадину...
{
    // Значит, кто-то уже успел обновить запись, пока ты тут думал.
    foreach (var entry in ex.Entries)
    {
        // Пытаемся достать то, что сейчас лежит в базе (тот самый надкушенный круассан)
        var databaseValues = await entry.GetDatabaseValuesAsync();
        if (databaseValues == null)
        {
            Console.WriteLine("Да запись-то уже удалили, о чём ты?");
        }
        else
        {
            // Вот актуальные данные из БД
            var dbProduct = (Product)databaseValues.ToObject();
            // И тут решай, страдалец, что делать:
            // 1. "Моё — моё!" (Client Wins) — перезаписать данные в БД своими.
            //    entry.OriginalValues.SetValues(databaseValues);
            //    await _context.SaveChangesAsync(); // Пробуем ещё раз
            // 2. "Ладно, сдаюсь" (Store Wins) — принимаем данные из БД.
            //    entry.CurrentValues.SetValues(databaseValues);
            // 3. Ручное мерджирование — это когда ты умный и пытаешься слить изменения.
            Console.WriteLine($"Конфликт, детка! Пока ты тупил, цена в БД стала {dbProduct.Price}");
        }
    }
}

3. Если ты мазохист и любишь SQL. Можно и руками, конечно:

UPDATE Products
SET Price = @NewPrice, Version = Version + 1
WHERE Id = @ProductId AND Version = @OriginalVersion;
-- Смотришь, сколько строк обновилось. Если ноль — значит, версия уже не та, тебя опередили.

Когда это юзать, а когда нет?

• Оптимистическая (про версии): Когда все редактируют разное, или конфликты раз в год. Производительность чтения — огонь, блокировок нет. Идеально для всяких каталогов, профилей юзеров.
• Пессимистическая (про блокировки): Когда идёт драка за последний ресурс. Типа «один билет на концерт» или «последняя пачка гречки». Тут сразу надо кричать SELECT ... FOR UPDATE и вешать замок на запись, пока не закончил. Чтение медленнее, зато ты уверен, что тебя не обгонят.

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