Я чувствую себя глупо, задавая этот вопрос, но чтобы прояснить ситуацию, иногда нужно задавать глупые вопросы:)
Итак, мы можем определить перекос записи, как это сделал Мартин Клеппманн в своем выступлении:
Написать наклонный рисунок:
1. читать что-то
2. принять решение
3. написать решение
Ко времени фиксации записи (3) предпосылка (1) решения (2) уже не верна
Существует пессимистический подход, когда мы в основном говорим, что «только один субъект может использовать общий ресурс в данный момент, другие должны подождать, пока предмет не закончится».
И затем есть оптимистический подход с фазами, как определено в Википедии:
I. Начало: запишите метку времени, обозначающую начало транзакции.
II. Изменить: прочитать значения базы данных и предварительно записать изменения.
III. Проверить: Проверьте, изменили ли другие транзакции данные, которые использовала эта транзакция (чтение или запись). Сюда входят транзакции, завершенные после времени начала этой транзакции, и, опционально, транзакции, которые все еще активны на момент проверки.
Внутривенно Фиксация / откат: если нет конфликта, все изменения вступают в силу. Если есть конфликт, разрешите его, как правило, прервав транзакцию, хотя возможны и другие схемы разрешения.
У меня вопрос: какие у нас гарантии того, что новое «знание» не записывается во время проверки (III), таким образом выполняя определение перекоса записи, данное выше?
По сути, этот модуль проверки на этапе III должен хранить некоторую внутреннюю книгу и обрабатывать их последовательно, чтобы процесс проверки из транзакции 2 не происходил до события записи транзакции 1.
Мы только что перенесли всю эту проблему асимметрии записи на один уровень вниз? Итак, у нас есть сериализуемый пессимистический подход на низком уровне, чтобы иметь возможность иметь оптимистичный подход на более высоком уровне? Я что-то не так делаю?
Буду признателен за любые разъяснения.